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INTERFACE  SPECIFICATIONS  FOR  THE  SCR  (A-7E) 
EXTENDED  COMPUTER  MODULE 

INTRODUCTION 


EC. INTRO 


The  Extended  Computer  (EC)  is  a  computing  machine  partially  implemented  in 
software.  It  was  designed  as  part  of  the  Software  Cost  Reduction  (SCR) 
project  at  the  Naval  Research  Laboratory.  The  design  goals  are  1)  code 
portability,  2)  abstraction  from  computer  hardware  idiosyncracies ,  3)  more 
easily  understood  code,  and  4)  sharing  of  solutions  to  common  machine 
dependent  coding  problems.  The  Extended  Computer  is  designed  to  be 
efficiently  implemented  on  avionics  computers  such  as  the  IBM  4PI  TC-2.  The 
instruction  set  allows  straightforward,  efficient  code  generation  using  a 
macroprocessor. 

The  Extended  Computer  has  the  following  features: 

1)  Extensible  addressing:  There  is  no  syntactic  limit  to  the  amount  of 
memory  that  can  be  addressed.  The  actual  memory  size  is  a  parameter 
that  is  set  at  system-generation  time. 

2)  Uniform  data  access:  Hardware  addressing  techniques,  such  as  use  of 
base  and  link  registers,  are  hidden  from  programmers. 

3)  Uniform  subprogram  access:  All  subroutines  are  invoked  in  a  uniform 
manner;  linkage  mechanisms  are  hidden  from  users. 

4)  Uniform  input/output :  Variations  in  I/O  operations  are  hidden.  All 
input  (output)  data  items  are  read  (written)  using  the  same 
statements. 

5)  Uniform  event  signalling:  The  difference  between  hardware  interrupts 
and  software-detected  events  is  hidden.  All  interrupt  handling  is 
hidden. 

6)  Data  types:  Data  types  representing  reals,  bitstrings,  and  time 
intervals  are  provided  together  with  the  necessary  conversion 
functions.  Data  representations  are  hidden.  Hardware  arithmetic  and 
bitstring  operations  are  hidden. 

7)  Parallel  processes:  Programs  can  be  written  as  a  set  of  cooperating 
sequential  processes.  The  number  of  hardware  processors  and  their 
scheduling  are  hidden. 

8)  State  control:  Computer  state  transitions  among  various  states 
(including  off,  operating,  and  failed)  are  signalled  to  the  user 
programs.  The  mechanics  of  state  transitions  are  hidden. 

9)  Built-in  test:  Diagnostic  programs  to  test  the  integrity  of  memory 
and  the  correct  operation  of  the  hardware  are  built-in.  The  tests 
and  evaluation  criteria  are  hidden. 

Manuicript  approved  October  23,  1984. 
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EC. INTRO 


10)  Exception  handling:  Both  a  development  version,  with  extensive 
checks  for  programming  errors,  and  a  production  version  are 
available.  Programs  that  cause  no  undesired  events  [WUER76]  on  the 
development  version  will  compute  the  same  values  on  both  versions. 
The  version  can  be  selected  at  system-generation  time. 


The  Extended  Computer  has  been  designed  to  hide  the  interface 
characteristics  of  a  computer  with  capabilities  similar  to  those  of  the  IBM 
4PI/TC-2.  Were  the  present  A-7  computer  to  be  replaced  by  one  with  different 
capabilities,  we  would  shift  some  responsibilities  to/from  other  parts  of  the 
software.  For  example,  if  the  new  computer  used  an  external  device  for 
timing,  the  implementation  of  the  timeint  data  type  would  become  a  part  of  the 
device  interface  modules.  Or,  if  the  new  computer  included  a  capability  for 
angle  implementation,  the  machine-independent  implementation  of  an  angle  data 
type  would  be  replaced  by  a  machine-dependent  module  that  was  part  of  the  EC, 
but  with  the  same  interface  as  the  present  angle  data  type.  Of  course,  under 
such  unlikely  circumstances,  the  appropriate  documentation  (such  as  [REQ], 
[MG],  and  [AT],  as  well  as  this  document)  would  be  changed  to  remain 
consistent  with  the  new  hardware.  If  the  EC  design  were  to  be  used  in  an 
application  that  did  not  require  all  of  its  capabilities,  a  compatible  subset 
could  be  used. 

We  recommend  that  this  procedure  be  followed  by  anyone  maintaining  this 
system,  and  by  those  who  are  designing  other  systems  using  a  similar  approach. 

This  document  specifies  the  user  interface  to  the  Extended  Computer.  The 
contents,  form,  and  notation  are  in  accordance  with  the  guidelines  given  in 
[SO],  with  the  following  addition. 

Events  signalled  by  incrementing  a  semaphore:  The  EC  signals  all 
events  by  incrementing  semaphores.  The  semaphores  and  the  events  they 
represent  are  listed  in  this  section.  The  semaphores  are  built-in  (users 
need  not  declare  them),  and  are  given  an  initial  value  of  zero  at  system 
generation  time. 
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DATA  MANIPULATION  FACILITIES 


EC. DATA. 1  INTRODUCTION 
EC. DATA. 1.1  ENTITIES 

The  Extended  Computer  provides  literals,  constants,  and  variables.  We 
refer  to  these  as  entities.  Literals  are  values  appearing  in  programs. 
Constants  have  names  and  values;  run-time  programs  can  read  the  values  but  not 
change  them.  Variables  have  names  and  values;  the  values  can  be  read  or 
written  by  run-time  programs.  A  register  is  a  variable  with  a  faster  access 
time  than  other  variables.  There  is  one  register  for  each  process  (see 
EC. PAR).  All  constants  and  variables  other  than  registers  may  be  accessed 
from  any  process  of  the  program.  It  is  possible  to  declare  arrays  of 
variables  or  constants.  An  element  of  an  array  may  be  used  as  an  individually 
declared  entity  of  the  same  type.  Users  are  given  the  facility  for  providing 
information  to  the  Extended  Computer  about  the  relative  speeds  with  which 
declared  entities  should  be  accessed. 


EC. DATA. 1.2  TYPES 

Types  are  classes  of  entities.  The  Extended  Computer  provides  a  hierarchy 
of  types;  an  entity  is  either  numeric,  bitstring  or  pointer.  Numeric  types 
are  characterized  by  range  and  resolution.  Bitstring  types  are  characterized 
hy  length.  The  value  of  a  pointer  is  another  entity.  Pointer  types  are 
characterized  by  the  type  of  entity  to  which  members  of  the  pointer  type  may 
refer.  The  value  of  a  characteristic  for  an  entity  is  called  an  attribute. 

For  a  particular  numeric  type,  every  numeric  value  between  the  upper  bound 
and  lower  bound  (inclusive)  has  a  representative  in  its  type.  Any 
representative  will  differ  from  its  nearest  neighbors  by  no  more  than  the 
resolution  of  the  type,  and  no  numeric  value  will  differ  in  value  from  its 
representative  by  more  than  half  the  resolution. 

For  numeric  types,  users  may  require  that  the  representatives  include 
exact  multiples  of  the  resolution  between  the  lower  and  upper  bounds, 
inclusively. 

A  type  class  is  a  type  that  contains  entities  with  different  behavior.  A 
specific  type  (also  called  spectype)  is  a  subclass  of  a  type  class  in  which 
all  variables  have  identical  behavior;  i.e.,  they  can  take  on  the  same  set  of 
values  and  one  may  perform  the  same  operations  on  them  with  the  same  results. 
The  behavior  of  the  program  will  not  change  if  two  variables  of  the  same 
specific  type  are  interchanged  throughout  the  program. 


For  each  type  class,  there  are  any  number  of  specific  types.  These  either 
have  fixed  attributes,  or  attributes  that  may  vary  at  run-time. 
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Figure  1  provides  an  overview  of  Che  EC  data  types  by  showing  the  Extended 
Computer's  type  classes  and  specific  types.  Lines  connect  a  type  with  its 
sub-types.  The  terminal  nodes  represent  specific  types,  of  which  entities  may 
be  declared.  Not  all  of  the  types  in  the  table  are  currently  implemented;  to 
see  which  ones,  refer  to  Appendix  4. 

The  Extended  Computer  provides  two  numeric  type  classes  illustrated  in 
Figure  1,  but  not  described  in  this  chapter.  They  are  semaphores  and  timers , 
whose  operations  are  described  in  EC.SMPH  and  EC. TIMER,  respectively.  The 
Extended  Computer  also  provides  the  program  type  class.  This  is  described  in 
EC. PGM. 2. 
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EC . DATA .1.3  SCALAR  LITERALS 

A  scalar  literal  belongs  to  exactly  one  of  the  type  classes  bitstring, 
real,  or  tiraeint,  and  may  belong  to  more  than  one  specific  type  of  its  tvoe 
class.  Formats  for  writing  literals  of  these  type  classes  are  specified  in 
the  type  definitions  for  these  type  classes  in  EC. DATA. 3. 

Numeric  literals  will  be  represented  with  at  least  the  precision  implied 
by  their  written  representation. 
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EC. DATA. 1.4  REGISTERS 

A  single  register  is  provided  t'or  each  process.  Run-time  operations  using 
the  register  are  likely  to  be  faster  than  operations  on  other  variables.  (A 
system-generation-time  program  cannot  use  the  register.)  A  register  is  a 
variable  with  varying  type  class  and  varying  attributes;  each  operation  that 
uses  a  register  must  include  information  sufficient  to  determine  a  type  class 
and  the  appropriate  attributes. 

A  process  cannot  access  the  register  of  another  process. 

The  contents  of  a  register  may  be  changed  by  a)  using  the  register  as  a 
! Idestination! 1 ,  or  b)  performing  an  operation  without  specifying  that  the 
register  contents  be  preserved.  Each  run-time  access  program  defined  in  this 
chapter  may  appear  with  or  without  a  suffix  "-SAVE"  (e.g.  +MINUS+  or 
+MINUS-SAVE+) .  Use  of  the  suffix  specifies  that  the  contents  of  the  register 
will  be  preserved  by  the  operation.  Omission  of  the  suffix  specifies  that  the 
contents  of  the  register  shall  be  the  same  after  execution  of  the  program  as 
immediately  before. 

Table  EC. DATA. b  shows  how  the  value  of  a  register  is  affected  by  an 
operation.  Value  undefined  indicates  that  the  value  contained  in  the  register 
is  unspecified.  If  a  program  reads  a  register  when  its  value  is  undefined, 
the  results  will  be  unpredictable. 


Table  EC. DATA. b:  Effects 


Register  use 

Suffix 

read  only 

none 

read  only 

-SAVE 

written  or 
read  and  written 

none 

written  or 
read  and  written 

-SAVE 

not  referenced 

none 

not  referenced 

-SAVE 

of  Operations  on  Register  Contents 

Effect  of  the  operation  on  Register 

value  undefined 

value  not  changed 

new  value  produced 
by  operation 

undesired  event 

value  undefined 
value  not  changed 


*.N 


CRF  155  251  252 


Release  7 


EC. DATA 


EC. DATA. 2  INTERFACE  OVERVIEW 

EC . DATA .2.0  DECLARATION  AND  RANKING  OF  DATA  SETS 

The  EC  requires  users  Co  assign  entities  to  data  sets.  The  user  is  then 
allowed  to  specify  a  partial  ordering  on  the  data  sets  to  determine  speed  of 
access  to  the  secs'  members.  The  rankings  apply  to  sections  of  code. 
Significant  performance  improvements  are  possible  if  the  entities  used  in  a 
section  of  code  belong  to  a  data  set  that  is  highly  ranked. 


Program  name 


Parm  info 


Undesired  events 


++DCL  DATA  SET++  pi: name; I  name  of  data  set  %Zname  in  use%% 

++RANK  DATA  SET++  pl:data-set-reln;I  None. 


Effects 

++DCL_DATA_SET++  Declares  pi  to  be  the  name  of  a  data  set,  and  allows  that 

name  to  be  used  as  p5  of  ++DCL__ENTITY++  and/or  p6  of  ++DCL 
ARRAY +•+ . 

•m-RANK_DATA_SET++  Defines  a  partial  ordering  on  all  data  sets;  if  (A,B)  is 

in  the  relation  given  by  pi,  then  data  set  A  has  a  higher 
rank  than  data  set  B.  Data  sets  not  named  in  pi  have  an 
arbitrary  rank  lower  than  any  set  named  in  pi. 

The  ranking  applies  until  the  next  textual  occurrence  of 
++RANK_DATA_SET++ . 

Access  to  entities  and  arrays  in  a  data  set  will  be  made 
not  slower  than  access  to  members  of  a  lower  ranked  data 
set. 
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EC. DATA. 2.1  DECLARATION  OF  SPECIFIC  TYPES 

All  specific  types  must  be  declared  and  given  a  name.  Numeric  types  are 
characterized  by  ! '.range!!  and  I  !  resolution!  ! ,  bitstring  types  by  length. 
Pointer  types  are  characterized  by  the  name  of  a  previously-declared  specific 
type.  The  type  declaration  must  indicate  whether  or  not  these  attributes  can 
vary  at  run-time.  The  EC  allows  users  to  choose  among  different  versions  of 
the  implementation  for  each  type;  each  version  is  especially  efficient  for 
performing  certain  operations.  The  versions,  and  the  advantages  and 
disadvantages  of  each,  are  specified  in  Appendix  6. 


Program  name  Parm  type 


Parra  info 


Undesired  events 


++DCL_TYPE++  p 1 : name ; I 

p2 : typeclass ;I 
p3:attribute  ;I 
p4 : binding ; I 

p5 : version ; I 


name  of  new  type 
containing  type  class 
attributes  of  type 
Can  attributes  vary 
at  run-time? 
implementation  version 


%%name  in  use%% 

%% inappropriate 
attr ibutes%% 
?%length  too 
great%% 

Grange  too 
great%% 
%%ranres  too 
great%% 

%%res  too  fine%% 
%%unknown  operand 
in  attribute%% 
%%undeclared 
spectype£% 


Program  Effects 


A  specific  type  that  is  a  member  of  type  class  p2  and  has  binding  p4  and 
implementation  version  p5  is  declared  to  have  identifier  pi.  If  p4=FIX,  then 
all  entities  and  arrays  of  this  specific  type  will  have  the  attributes  given 
by  p3 .  If  p4=VARY,  then  p3  gives  the  !!hardest  attributes!!  that  any  entity 
or  array  of  this  spectype  will  ever  assume.  If  p5  is  not  a  version  associated 
with  the  given  type,  as  specified  in  Appendix  6,  then  the  EC  implementation 
will  use  an  appropriate  version  of  its  own  choosing.  The  identifier  can  be 
used  as  the  spectype  (p2)  parameter  in  calls  on  ++DCL_ENTITY++  and 
++DCL_ARRAY++  in  programs  that  follow  the  declaration. 
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EC. DATA. 2. 2  DATA  DECLARATIONS 

EC. DATA. 2. 2.1  DECLARATION  OF  VARIABLES  AND  CONSTANTS 

Variables  and  constants  must  be  declared  before  they  are  used.  The 
declaration  must  specify  the  name  of  the  new  entity,  a  previously  declared 
specific  type  (one  of  the  terminal  nodes  on  the  tree  of  figure  1),  whether  the 
entity  is  a  constant  or  a  variable,  and  an  initial  value. 

Program  name  Parm  type  Parm  info  Undesired  events 


++DCL_ENTITY++  pi: name; I  entity  name 

p2 : spectype;I  entity's  specific  type 

p3:convar;I  when  writeable? 

p4:constant  or  initial  value 

literal  whose 
value  is  in 
domain  of  type 
named  by  p2 ; I 

p5 : data_set ; I  data  set  name 


%%name  in  use%% 
%%undeclared 
spectype%% 
%%unknown  initial 
value%2 
%%varying 

constant%% 
%%wrong  init 
value  type%% 
%%loadcon  too  big%% 
%%literal  or  ascon 
too  big%% 


Program  Effects 

An  entity  with  identifier  pi,  spectype  p2,  and  initial  value  p4  is 
declared.  If  p3=VAR,  the  entity  may  be  used  as  a  l idestinationl !  in  a 
subsequent  operation.  The  entities  that  have  been  declared  may  be  used  as 
operands  in  the  programs  that  follow.  The  entity  is  assigned  to  data  set  p5. 
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EC. DATA. 2. 2. 2  DECLARATION  OF  ARRAYS 


Program  name 

Parm  type 

Parra  info 

Undesired  events 

++DCL_ARRAY++ 

pi : name ; I 
p2: spectypejl 
p3 : convar ; I 
p4:array-init;I 
p5: indexset  ;I 
p6:data_set;I 

array  name 
element  type 
when  writeable? 
initial  value 
array  indices 
data  set  name 

as  for  ++DCL  ENTITY** 
plus : 

%%wrong  init 
value  size%% 
%%illegal  index  setZZ 

Program  Effects 

A  one-dimensional  array  with  identifier  pi,  spectype  p2,  initial  value  p4, 
and  index  set  p5  is  declared.  If  p3=VAR,  the  elements  of  the  array  may  be 
used  as  !  1 destination! s  in  subsequent  operations.  The  array  is  declared  to 
belong  to  data  set  p5.  Elements  of  the  array  can  be  used  wherever  an  entity 

of  Che  same  specific  Cype  could  be  used.  An  array  may  also  be  a  parameter  to 
a  user-defined  program. 
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EC. DATA. 2. 3  ACCESS  SPEED  RANKING  OF  DATA 


The  Extended  Computer  can  implement  a  "not-slower-than"  relation  between 
any  two  variables,  constants,  or  arrays. 

Program  name  Parm  type  Parm  info  Undesired  events 

++RANK__DATA++  pi :rank-data-relation; I  %%undeclared 

operand%% 

%%inconsistent  data 
ranking%% 


Program  effects 

Let  A  and  B  be  previously  declared  arrays,  constants,  or  variables.  If 
the  rank-data-relation  for  this  invocation  of  the  program  includes  (A,B),  then 
using  A  (or  an  element  of  A  if  A  is  an  array)  as  an  operand  in  an  EC  program 
will  take  no  longer  than  using  B  (or  an  element  of  B  if  B  is  an  array)  in  the 
same  program,  if  both  are  in  the  same  data  set.  The  rank  relation  for  all  EC 
data  objects  is  composed  of  the  rank-data-relations  given  in  each  invocation 
of  this  program.  The  relation  is  transitive,  antireflexive,  and  antisymmetric 


CRF  131  132  266 


Release  7 


EC. DATA 


EC. DATA. 2. 4  OPERAND  DESCRIPTIONS 


EC. DATA. 2. 4.1  INDIVIDUAL  PARAMETERS 


Table  EC. DATA. c  summarizes  the  description  of  operands  for  EC  run-time 
access  programs  and  user-defined  programs.  Brackets  shown  are  required. 

Table  EC. DATA. c  INDIVIDUAL  PARAMETER  SPECIFICATION 


Nature  of  Parameter 


Literal 


Form  of  Parameter 


Literal  value 


Scalar  constant  or  variable  Name  of  entity 
without  qualifier(s) 


Qualified  parameter 


^  Name  of  entity  or  array,  qualifier-list^" 
where  qualifier-list 

qualifier  OR 
qualifier-list,  qualifier 


Entity  referred  to  by  a  (  DEREF  ,  entity^* 

pointer 

The  latter  two  forms  are  discussed  below. 

EC. DATA. 2. 4. 1.1  QUALIFIED  PARAMETERS 

Variable  with  varying  attributes:  The  attributes  must  be  specified.  A 
qualifier  is  given  that  is  the  name  of  a  previously-declared  specific  type 
with  fixed  attributes.  If  the  attributes  thus  specified  when  the  variable  is 
used  as  a  Ilsourcell  are  not  the  same  as  when  that  variable  was  most  recently 
used  as  a  1 1  destination! 1 ,  the  results  are  undefined. 

Register:  If  the  parameter  is  the  register,  the  name  of  the  entity  is 

REG.  The  typeclass  and  attributes  must  be  specified  by  giving  a  qualifier 
that  is  the  name  of  a  previously-declared  specific  type  with  fixed 
attributes.  If  the  attributes  thus  specified  when  REG  is  used  as  a  Ilsourcel! 
are  not  the  same  as  when  it  was  most  recently  used  as  a  ! ^destination! I ,  the 
results  are  undefined. 

Array  elements:  If  the  parameter  is  an  element  of  an  array,  the  index  is 
given  as  a  qualifier.  It  may  be  any  integer  entity  (including  an  element  of 
an  integer  array).  The  element  specified  is  chosen  before  the  operand  in 
which  the  parameter  appears  is  performed.  An  array  element  may  be  used 
anywhere  that  an  entity  with  the  3ame  attributes  may  be  used. 
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Rounding  numeric  results:  The  qualifier  ROUND  may  be  given  with  any 
numeric-!  destination! !  variable  with  the  EXACT_REP  attribute.  This  has  the  -- 

effect  of  storing  into  the  variable  the  integer  multiple  of  the  variable's  • 

current  I  !  resolution! !  that  is  closest  to  the  actual  result  of  the  operation 
in  which  it  appears. 

Truncating  numeric  results:  The  qualifier  TRUNC  may  be  given  with  any 
numeric  1 ! destination! I  variable  that  has  the  EXACT_REP  attribute.  This  has  -- 

the  effect  of  storing  a  value  into  the  variable  such  that  (a)  y  is  one  of  the 
two  integer  multiples  of  the  variable's  current  ! Iresolution! !  closest  to  the 
value  resulting  from  the  operation;  and  (b)  absv(y)  It  absv(computed  result). 

Specifying  subrange  information  for  variables:  The  user  may  supply  range 
information  when  a  numeric  variable  is  used  as  a  parameter.  The  qualifier  is  - 

of  the  form 

lb  :  ub 

where  "lb"  and  "ub"  are  the  lower  and  upper  bound,  respectively,  of  the 
variable,  given  as  literals  or  ascons  within  the  range  of  the  variable. 

Specifying  a  subrange  for  a  !! destination! !  of  an  operation  asserts  that  the 

result  of  the  operation  will  be  within  the  subrange  given.  Specifying  a 

subrange  for  a  !! source!!  of  an  operation  asserts  that,  at  the  time  of  the  - 

call,  the  operand  will  have  a  value  within  that  subrange.  A  subrange 

specification  for  an  10  parameter  is  interpreted  as  the  conjunction  of  both 

!!source!!  and  ! destination! !  assertions.  The  implementation  may  be  based  on 

the  assumption  that  the  assertion  is  true,  and  results  will  be  unpredictable 

if  the  assertion  is  violated.  , 

i  .  ,  V 

Meaningful  combinations  of  qualifiers:  The  following  combinations  of 

qualifiers,  and  of  entities  and  qualifiers,  are  not  allowed: 

-  ROUND  and  TRUNC  both  occurring  in  the  same  parameter  specification; 

-  more  than  one  occurrence  of  the  same  kind  of  qualifier; 

,  -  attribute  specification  for  a  fixed-attribute  variable  or  a  constant;  , 

j  -  ROUND  or  TRUNC  with  an  entity  not  having  the  EXACT_REP  attribute,  or 

with  an  entity  that  is  not  a  !! destination! 1 ; 

-  an  array  index  with  an  entity  that  is  not  an  array; 

-  a  subrange  specification  for  a  non-numeric  entity. 

.  i 

EC. DATA. 2. 4. 1.2  USING  POINTERS  ‘ 

Anywhere  that  an  entity  may  be  used,  the  reference  may  be  replaced  by 

^DEREF, pointer^ 

where  "pointer"  is  the  name  of  a  previously-declared  entity  of  the  PTR 
typeclass .  This  has  the  same  effect  as  using  the  entity  that  is  the  current 
value  of  the  pointer. 
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EC. DATA. 2. 4. 2  LISTS  OF  DESTINATIONS 


Any  ! ! actual  parameter!!  given  for  an  0  (output)  parameter  in  an  EC  access 
program  may  be  given  as  a  ! ! 1 is t ! !  of  operands  (possibly  including  the 
register).  Each  element  of  the  I  Hist!  I  must  be  suitable  for  use  as  a 
destination  of  the  operation.  All  of  the  parameters  will  receive  the  same 
value  (subject  to  any  ROUND  or  TRUNC  effects);  the  assignments  may  be  made  in 
an  arbitrary  order  or  simultaneously. 


EC. DATA. 2. 4. 3  NOSTORE 

The  special  identifier  (not  an  entity)  NOSTORE  may  be  used  in  place  of  an 
! ! actual  parameter!!  for  an  0  (output)  parameter  in  an  EC  access  program. 

This  has  the  effect  of  not  storing  the  computed  result  into  any  entity, 
although  the  computed  value  can  be  used  to  determine  the  exit  of  the  program 
(see  EC . PGM. 1 ) . 


EC. DATA. 2. 4. 4  UNDESIRED  EVENTS 

The  following  undesired  events  can  occur  when  parameters  are  specified 
using  the  forms  described  in  this  section: 

^assertion  violation!? 

ZZattribute  not  allowed** 

ZZattribute  not  given** 

Zillegal  array  index* 

ZZillegal  ptr  target!?!? 

Zillegal  round/trunc* 

%Z inappropriate  attributes*! 

ZZinconsistent  register  access*! 

** index  not  allowed** 

ZZliteral  or  ascon  too  big** 

ZZmultiple  qualifiers** 

ZZREG  not  allowed** 

ZZres  too  fine** 

**subrange  not  allowed** 

ZZundeclared  operand** 

**undeclared  spectypeZZ 
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EC. DATA. 2. 5  TRANSFER  OPERATIONS 


Program  name 


Parm  type 


Parm  info 


Undesired  events 


+SET+ 

++SET++ 


pl:see  belowjl 
p2:see  below;0 


l+source+!  %inconsistent  lengths% 

!+destination+!  Grange  exceeded% 


Parameters 


pi  and  p2  must  be  either  both  real,  or  both  timeint,  or  both  bitstrings  of 
the  same  length,  or  both  pointers  of  the  same  specific  type. 


Program  Effects 


p2  =  the  value  of  pi  before  the  operation. 
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EC. DATA. 2. 6  NUMERIC  OPERATIONS 

EC. DrtTA. 2. 6.1  NUMERIC  COMPARISON  OPERATIONS 


Program  name  Parm  type 


Parm  info 


Undesired  events 


+EQ+ 

pi: see  below; I 

+NEQ+ 

p2:see  below; I 

+GT+ 

p3 : boolean;0 

+GEQ+ 

p4:see  below; I 

*LT+ 

+LEQ+ 

!+source+!  None 

I +source+! 

!+destination+! 

!+user  threshold*! 


Parameters 


pl,p2,p4  must  be  either  all  real  types  or  all  timeint  types. 


Program  Effects 


+EQ+  p3  =  (pi  =  p2 )* 

+NEQ+  p3  **  NOT  (pi  =  P2 )* 

+GT+  p3  ■  pi  -  p2  is  positive  and  NOT  (pi  =  p2)* 

+GEQ+  p3  =  (pi  *  p2)*  OR  (pi  -  p2  is  positive) 

+-LT+  p3  =  pi  -  p2  is  negative  and  NOT  (pi  *  p2)* 

+LEQ+  p3  *  (pi  *  p2)*  OR  (pi  -  p2  is  negative) 


♦Definition  of  equality  (=) : 

absv(pl  -  p2)  is  less  than  or  equal  to  !+user  threshold*!. 


1 

i 


a 


a 


f 


i 


j 

i 


i 
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EC. DATA. 2. 6. 2 

NUMERIC  CALCULATIONS 

Program  name 

Parm  type 

Parm  info 

Undesired  events 

+ABSV+ 

pl:see  below;I 

!+source+! 

Grange  exceeded? 

+C0MPLE+ 

p2:see  below;0 

!+destination+I 

+ADD+ 

pl:see  belowjl 

I +source+I 

+MUL+ 

p2:see  below;I 

! +source+! 

+SUB+ 

p3:see  below;0 

l+destination+! 

+DIV+ 

pi: see  belowjl 

l+source+! 

?range  exceeded? 

p2:see  be low; I 

! +source+ ! 

^divide  by  zero? 

p3 : boolean; I 

check  for  success? 

%%variable  parm?? 

p4:see  belowjl 

!+destination+! 

+SIGN+ 

pi :  see 

below; I 

!+source+!  of  sign  None. 

p2 : see 

below; I 

!+source+!  of  magnitude 
!+destination+! 

p3 : see 

below; I 

Parameters 

+ADD+ 

(1) 

all 

operands 

real,  or 

+ABSV+ 

+COMPLE+ 

+SUB+ 

(2) 

all 

operands 

timeint 

+MUL+ 

(1) 

all 

operands 

real,  or 

(2)  one  of  pi  or  p2  real,  the  other  operands  timeint 

♦DIV+  (1)  pl,p2  and  p4  real,  or 

(2)  pi  and  p2  timeint  and  p4  real,  or 

(3)  pi  timeint,  p2  real,  p4  timeint; 

p3  must  be  given  by  a  literal  or  ascon. 

+SIGN+  (1)  pi,  p2,  p3  real;  or 

(2)  pi,  p2,  p3  timeint. 
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+ABSV+ 

+ADD+ 

+COMPLE+ 

+MUL+ 

+SIGN+ 

+SUB+ 

+DIV+ 


DIV  FAIL 


Program  Effects 

p2  =  magnitude(pl) 
p3  =  pi  +  p2 
p2  =  -  pi 
p3  =  ?!  *  p2 

p3  =  sign(pl)  *  absv(p2),  where  sign(O)  is  defined  to  be  0. 
p3  =  pi  -  p2 

If  a  subrange  assertion  (lb:ub)  was  given  for  p4  AND 
absv(ub)  It  absv(pl/p2)  then: 

(a)  if  p3*$true$  then  sign(p4)=sign(pl/p2) ,  magnitude 
of  p4  is  undefined,  and  the  built-in  program 
entity  DIV_FAIL  is  invoked; 

(b)  if  p3=$false$  then  p4  is  undefined. 

Otherwise,  p4  =  pl/p2. 


Built-in  Objects 


A  program  variable  of  spectype  El  (defined  in  EC. PGM. 2. 3). 
DIV_FAIL  has  no  initial  value;  if  it  is  invoked  before 
assigning  a  value  to  it,  the  UE  ^uninitialized  pgm%  (defined 
in  EC. PGM. 2.5)  will  be  raised. 


vi 


1 


1 


. 
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EC. DATA. 2. 6. 3  OPERATIONS  CONVERTING  OTHER  TYPES  TO  REALS 


Program  name  Parm  type  Parm  info 


+R_BITS_2COMP+ 
+R_BITS_POSITIVE+ 
+R  BITS  SIGNMAG+ 


pl:bitstring;I 
p2 : integer ; I 
p3 : real  ;0 


I +source+ I 
!+radix  pt  ident+! 
!+destination+! 


+R_TIME_HOUR+ 

+R_TIME~MIN+ 

+R_TIME_MS+ 

+R  TIME  SEC+ 


pi : t imeint ; I 
p2 :real ;0 


l +source+ ! 
!+destination+l 


Undesired  events 
%range  exceeded% 


Program  effects 


+R  BITS  2COMP-I 


+R  BITS  POSITIVE+ 


+R  BITS  SIGNMAG+ 


+R__TIME_HOUR+ 

+R_TIME_MIN+ 

+R_TIME_MS+ 

+R  TIME  SEC+ 


p3  =  real  value  equivalent  to  pi  assuming  that  bitstring  pi 
is  in  a  two's  complement  representation,  bit  0  is  the  most 
significant  bit,  and  the  radix  point  is  specified  by  p2. 


p3  =  real  value  equivalent  to  pi  assuming  that  bitstring  pi 
represents  a  positive  number,  with  bit  0  the  most 
significant  bit,  and  the  radix  point  is  specified  by  p2. 


p3  =  real  value  equivalent  to  pi  assuming  that  bitstring  pi 
is  in  a  sign  magnitude  representation,  bit  0  is  the  most 
significant  bit,  and  the  radix  point  is  specified  by  p2. 


p2  =  a  real  value  giving  the  time  pi  in  hours. 

p2  =  a  real  value  giving  the  time  pi  in  minutes. 

p2  ■  a  real  value  giving  the  time  pi  in  milliseconds. 

p2  =  a  real  value  giving  the  time  pi  in  seconds. 
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EC. DATA. 2. 6. 4  OPERATIONS  CONVERTING  TO  TIME  INTERVALS 


Program  name 

+T_REAL_MS+ 
+T_REAL  SEC+ 

+t_real“min+ 

+T  REAL  HOUR+ 


+T  REAL  MS+ 


+T  REAL  SEC+ 


+T  REAL  MIN+ 


+T  REAL  HOUR+ 


Parm  type 

pi : real ;  I 
p2 : timeint ;0 


Parm  info 

1 +source+! 
1+destination+I 


Program  effects 

p2*timeint  value  equivalent  to  pi 
the  time  interval  in  milliseconds. 

p2*timeint  value  equivalent  to  pi 
the  time  interval  in  seconds. 

p2=timeint  value  equivalent  to  pi 
the  time  interval  in  minutes. 

p2®timeint  value  equivalent  to  pi 
the  time  interval  in  hours. 


CRF  177 


Undesired  events  | 

Grange  exceeded% 

i 

assuming  pi  to  specify 

I 

assuming  pi  to  specify 
assuming  pi  to  specify 

! 

assuming  pi  to  specify 
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EC. DATA. 2. 7  OPERATIONS  FOR  THE  BITSTRING  TYPE  CLASS 

Bits  in  all  bitstring  types  are  numbered  from  0  upward.  We  refer  to  bit  0 
as  the  leftmost  bit  and  a  shift  of  information  from  higher  numbered  bits  to 
lower  numbered  bits  as  a  left  shift. 

EC. DATA. 2. 7. 1  BITSTRING  COMPARISON  OPERATIONS 


Program  name  Parm  type 


Parm  info 


+EQ+ 

+NEQ+ 


pl:bitstring;I 
p2 : bitstring ; I 
p3 : boolean  ;0 


i+source+ I 
!+source+ ! 

I +destination+ ! 


Program  Effects 


+EQ+  p3  =  (pi  =  p2)* 

+NEQ+  P3  =  NOT  (pi  =  p2)* 


Undes ired  events 
None . 


*Definition  of  equal  (=)  length(pl)  =  length(p2)  and 

for  all  i  such  that  0  Iseq  i  It  length(pl) 
bit  (i)  of  pi  =  bit  (i)  of  p2 
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BITSTRING  CALCULATIONS 

Program  name 

Parm  type 

Parm  info 

Undesired  events 

♦AND* 

♦CAT* 

♦MINUS* 

♦NAND+ 

♦OR* 

+X0R+ 

pi : bit  string  ;  I 
p2 : bit  st ring ; I 
p3 : b  itstr  ing ;0 

I +source+ ! 

!+source+! 

!+destination+I 

%inconsistent 

lengths% 

+NOT+ 

pi : bitstring; I 
p2:bitstring;0 

i+source+! 

i+destination+I 

♦SHIFT* 

pi : bitstring ; I 
p2 : integer ; I 
p3 : bitstr ing ;0 

I +source+ ! 
shift  length 
!+destination+I 

+REPLC+ 

pl:bitstring;I 
p2 : integer ; I 
p3 : integer ; I 
p4 : integer ; I 
p5 :bitstring;I 
p6 : bitstring ; 0 

!+source+! 

source  start  position 
destination  start  position 
length 

background  !+source+! 
!+destination+! 

%nonexistent 
pos i t ion% 
%incons istent 
lengths% 

Program  Effects 

+AND+ 

♦CAT* 

♦MINUS* 

+NAND+ 

♦  NOT* 

+OR+ 

+REPLC+ 

♦SHIFT* 

+XOR+ 

p3  =  pi  AND  p2 
p3  =  pi  followed  by  p2 
p3  »  pi  AND  (NOT  p2 ) 
p3  =  NOT  (pi  AND  p2) 
p2  =  NOT  pi 
p3  =  pi  OR  p2 

p6[p3:p3+p4-l]  =  pi [p2 : p2+p4-l] 
p6[all  other  bits]  =  corresponding  bits  in  p5 
p4  =  shift  of  pi  by  p2  positions  to  the  right 
positions  to  the  left).  The  vacated  bits  are 
p3  =  (pi  AND  (NOT  p2 ) )  OR  ( p2  AND  (NOT  pi)) 

(or  -p2 
set  to  "0:B". 
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EC. DATA. 2. 7. 3.  OPERATIONS  CONVERTING  TO  BITSTRING 
Program  name  Parm  type  Parm  info 


+B_REAL_2COMP+  pi: real; I  i+source+! 

+B_REAL_POSITIVE+  p2 : integer ; I  l+radix  pt  ident+! 

+B_REAL_SIGNMAG+  p3 :bitstring ;0  ! +destination+! 


Undesired  events 
%left  truncation% 


Program  Effects 

+B_REAL_2COMP+  p3  *  two's  complement  representation  of  pi,  such  that  the 

radix  point  of  the  resulting  bitstring  is  positioned 
according  to  p2.  Bit  0  of  p3  will  be  the  most 
significant.  The  operation  truncates  all  bits  beyond  the 
highest  numbered  bit  in  the  !+destination+!  bitstring. 

+BJREALJPOSITIVE+  p3  =  bitstring  representation  of  ABSV(pl),  such  that  the 

radix  point  of  the  resulting  bitstring  is  positioned 
according  to  p2.  Bit  0  of  p3  will  be  the  most 
significant  bit.  The  operation  truncates  all  bits  beyond 
the  highest  numbered  bit  in  the  !+destination+!  bitstring. 

+B_REAL_S  IGNMAG+  p3  *  sign  magnitude  representation  of  pi,  such  that  the 

radix  point  of  the  resulting  bitstring  is  positioned 
according  to  p2.  Bit  0  will  be  the  sign  bit  and  bit  1 
the  most  significant  bit  of  the  magnitude.  The  <~p.  ration 
truncates  all  bits  beyond  the  highest  numbered  bit  in  the 
! +destination+!  bitstring. 


EC. DATA. 2. 8  OPERATIONS  FOR  THE  POINTER  TYPE  CLASS 
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[ype  Definitions 


A  description  of  a  list  of  constant  or  literal  initial 
values  for  an  array.  The  list  must  contain  exactly  as  many 
members  as  there  are  elements  in  the  array.  If  the  array 
is  numeric,  all  values  must  be  within  the  ! '.range!!  of  the 
specific  type  of  the  array.  If  the  array  is  bitstring,  all 
values  must  be  of  the  the  same  length  as  the  specific  type 
of  the  array.  The  syntax  is: 

array-init  ::=  count. prod  (  elem.list  ) 
count. prod  empty  OR  count. prod  *  count 

count  ::=  positive  integer  constant  or  literal 

elem.list  ::  =  elem  OR  elem.list  ,  elem 
elem  ::=  constant  or  literal  of  type  appropriate  to 

the  array 
OR  array-init 

empty 

An  empty  count  has  the  value  of  1.  The  meaning  of 
count. prod  *  count  is  the  product  of  count. prod  and  count. 
The  meaning  of  count. prod  (  elem.list  )  is  count. prod 
occurrences  of  elem.list,  with  the  parentheses  removed  and 
the  occurrences  separated  by  commas.  Examples: 

*3(a,b)  (a,b,a,b,a,b) 

*3*2(a)  **  (a, a, a, a, a, a) 

*2(*3(a) ,*l(b) )  **  (a, a, a, b, a, a, a, b) 

(a)  =“  (a) 

An  attribute  for  a  bitstring  is  a  positive  integer 
specifying  length. 

A  real  or  timeint  attribute  is  a  parenthesized  list: 

(lower  bound,  upper  bound,  ! I  resolution! ! ,  EXACT_REP) 
The  fourth  element  is  optional;  if  omitted,  the  third  comma 
is  also  omitted.  The  lower  bound  and  upper  bound  are  often 
collectively  called  "range"  (see  Ilrange!!).  If  present  in 
a  type  declaration,  EXACT_REP  specifies  that  results  to  be 
stored  in  a  variable  of  that  type  may  be  truncated/rounded 
(at  the  discretion  of  the  user)  to  a  value  that  is  a 
multiple  of  the  variable's  current  !  '.resolution!  1 . 

!. 'Range!!  and  ! Iresolution! !  for  reals  must  given  by  real 
entities,  and  by  timeint  entities  for  timeints. 

A  pointer  attribute  is  the  name  of  a  previously-declared  or 
built-in  specific  type. 

Attributes  for  other  typeclasses  are  given  in  EC.SMPH  and 
EC. TIMER. 
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binding  Either  FIX  (meaning  attributes  do  not  change  at  run  time) 

or  VARY  (meaning  attributes  may  change  at  run  time) 

bitstring  An  ordered  list  of  values,  each  value  represented  by  "0"  or 

"1".  The  number  of  such  values  is  called  the  length  of  the 
bitstring.  A  bitstring  literal  is  written  as  a  string  of 
Os  and  Is  suffixed  by  ":B".  E.g., 

0: B  bitstring  of  length  1 

1011 :B  bitstring  of  length  4 

boolean  Bitstring  of  length  1.  Where  convenient,  $true$  may  denote 

"1:B",  $false$  may  denote  "0:B". 

convar  Either  ASCON  (meaning  constant  that  will  not  change  without 

a  reassembly)  or  LOADCON  (meaning  constant  that  may  be 
changed  by  a  memory  loading  device  while  the  program  is  not 
running)  or  VAR  (meaning  variable). 

data_set  A  group  (previously  declared  by  ++DCL_DATA_SET++ )  of 

user-defined  entities  that  the  user  may  rank  according  to 
desired  access  speed. 

data-set-reln  A  partial  ordering  on  the  set  of  all  data  sets,  given  as  a 
I 1  relation! 1 . 

indexset  A  set  of  permissible  indices.  Only  sets  of  contiguous 

integers  may  be  created.  The  set  must  be  specified  in  the 
following  way: 

(si, li) 

where  "si"  denotes  the  smallest  index  and  "li"  denotes  the 
largest  index.  Both  si  and  li  must  be  integer  ascons  or 
literals.  For  example,  (7,12)  indicates  a  six-element 
■.  array  indexed  by  the  integers  from  7  through  12.  (-4,-4) 

indicates  a  one-element  array  whose  index  is  -4. 

integer  Real  with  "resolution!!  =  1. 

name  An  identifier  for  an  object  created.  A  name  must  consist 

only  of  alphanumerics  or  one  of  the  following:  +#%@/$()_ 

pointer  A  type  that  provides  indirect  referencing  to  other  declared 

entities.  A  pointer  literal  is  given  by  ^REF,x^  where  "x" 
is  another  non-literal  entity;  "x"  may  not  be  REG  or  an  i/o 
data  item  (see  EC. 10). 

rank-data-  A  "relation!!  between  entity  and/or  array  names. 

relation 
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real  An  approximation  to  conventional  real  numbers.  Real 

literals  are  denoted  in  one  of  the  following  formats: 

standard  decimal  notation  e.g.  -112.345,  .000234,  127 

exponent  notation:  decimal  number,  followed  by  :En, 
where  n  is  an  integer,  meaning  that  the  value  is  the 
number  multiplied  by  10n 

e.g.  1. 12345 :E2  (*  112.345);  2.34:E-4  (*.000234) 

power  of  two  notation  2**n,  where  n  is  an  integer; 
e.g.,  2**3  (=  8);  2**- 4  (*.0625);  -2**4  (=-16) 

spectype  An  identifier  that  has  been  previously  declared  as  a  type 

in  a  ++DCL  TYPE++  operation,  or  the  name  of  a  spectype 
built  in  to  the  EC.  The  latter  includes  BOOLEAN 
(representing  the  built-in  bitstring  type  "boolean"),  as 
well  as  those  named  in  EC. PGM. 2  and  EC. 10. 

Representation  of  a  time  interval.  Literals  of  type 
timeint  are  denoted  by  using  the  name  of  one  of  the 
real-to-timeint  conversion  programs  of  EC. DATA. 2. 6. 4  and  a 
real  literal.  The  form  is: 

^program-name  ,  real-literal^ 

Where  a  blank  appears,  any  number  of  blanks  (including 
zero)  may  appear.  The  value  thus  specified  is  that  which 
would  be  returned  by  the  named  program  were  it  called  with 
the  real  as  the  input  parameter.  For  example, 

^+T_REAL_SEC+ ,  4.0^  denotes  a  timeint  value  of  4  seconds. 

Either  BITS  (meaning  bitstring),  PTR  (meaning  pointer), 
REAL,  or  TIMEINT  (meaning  time  interval).  Other  values  are 
SEMAPHORE  (see  EC.SMPH),  PGM  (see  EC. PGM. 2),  and  TIMER  (see 
EC. TIMER). 

version  A  version  name  applicable  to  the  specific  type  being 

declared.  Version  names  and  characteristics  are  listed  in 
Appendix  6. 
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EC. DATA. 4  Dictionary : 

Term  Definition 

!+destination+!  variable,  register  or  a  list  of  such  entities; 

will  contain  results  of  operation. 

!!  destination  I '.  An  0  or  10  !!  actual  parameter  I!  to  an  EC  access 

program  or  a  user-defined  EC  program. 

I '.hardest  attributes  II  For  bitstring  types,  the  maximum  length  that  an 

entity  of  this  spectype  will  ever  assume. 

For  real  or  timeint  types,  the  Ilrangell  and 
1 1  resolution! I  such  that  the  ratio  of  Ilrangell 
to  1 1  resolution! I  is  the  maximum  that  an  entity 
of  this  spectype  will  ever  assume,  where 
Ilrangell  is  defined  as  ABSV(upper  bound  - 
lower  bound).  Further,  if  an  entity  of  this 
spectype  will  ever  have  the  EXACT_REP  attribute, 
it  must  be  specified  here. 

The  syntax  for  specifying  Ilhardest  attributes!! 
is  the  same  as  for  attributes,  defined  in 
EC. DATA. 3. 

Illistl!  An  unordered  sequence  of  elements.  The  syntax  of 

a  Illistl!  is: 


item 

OR  (  item  ,  ...  ,  item  ) 

!+radix  pt  ident+!  Interpreting  the  bitstring  as  a  binary  real 

number  with  bit  0  the  most  significant  bit,  2 
raised  to  the  !+radix  pt  ident+!  power  is  the 
significance  of  the  rightmost  (highest  numbered) 
bit.  For  instance,  a  value  of  zero  means  that 
the  bitstring  represents  an  integer. 

Ilrangell  The  set  of  values  between  (and  including)  the 

lower  bound  and  upper  bound  of  a  numeric  data 
type. 

Ilrelation!!  A  set  of  ordered  pairs.  In  EC,  a  !  '.relation!!  is 

specified  by  giving  two  ! Hist!  Is;  the  ordered 
pairs  is  that  obtained  by  taking  the 
cross-product  of  the  !! lists!!.  The  syntax  is: 

::=  (  ! !  list! !  ,  Hlist!!  ) 
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!  [resolution! The  maximum  difference  between  any  two 

consecutive  representatives  of  the  values  of  a 
real  or  timeint  data  type. 

!  +source+!  variable,  register,  literal  or  constant;  has  a 

value  to  be  used  as  input  to  the  operation. 

Ilsource!!  An  I  or  10  llactual  parameter!!  to  an  EC  access 

program  or  a  user-defined  EC  program. 

!+user  threshold*!  A  difference  that  user  programs  specify  for  a 

comparison  operation;  i.e.,  two  numbers  whose 
difference  is  less  than  this  are  considered  equal. 


EC. DATA. 5  Undesired  Event  Dictionary: 

%assertion  violation%  A  variable's  value  was  not  in  the  [lb,ub] 

!! range!!  specified  in  a  subrange  assertion. 

%%attribute  not  allowedZZ  A  fixed-attribute  entity  was  given  using  the 

variable-with-varying-attributes  form  of 
parameter  specification. 

ZZattribute  not  givenZZ  An  attribute  qualifier  was  not  given  for  an 

operand  that  is  of  varying-at tribute  spectype. 

Zdivide  by  zeroZ  A  user  program  attempted  to  divide  by  zero. 

%il legal  array  indexZ  The  index  supplied  in  an  array  reference  is 

not  in  the  index  set  of  the  array. 

ZZillegal  index  setZZ  The  index  set  of  an  array  is  not: 

(a)  contiguous 

(b)  in  ascending  order 

(c)  integers 

(d)  given  with  ascons  or  literals. 

ZZillegal  ptr  targetZZ  A  pointer  may  not  point  to  REG,  nor  to  an  i/o 

data  item. 

Zillegal  round/truncZ  A  user  specified  ROUND  or  TRUNC  for  a  variable 

that  does  not  have  the  EXACTJREP  attribute  or 
is  not  a  ! Idestination! ! ,  or  tried  to  round 
and  truncate  the  same  numeric  result. 

ZZinappropriate  The  attributes  given  are  not  valid  for  the 

attributesZZ  type  class  at  hand. 


CRF  107  111  121  133  139  143  158  170 
171  240  262 


7726a 


28 


Release  7 


EC. DATA 


inconsistent  data 
ranking%% 

%inconsistent  lengths*! 

%%inconsistent  register 
access%% 

%Zindex  not  allowed%% 
%left  truncation% 

%%length  too  great%% 

%%literal  or  ascon 
too  big%% 

%%loadcon  too  big%% 

%mdr  outside  range% 
%%multiple  qualifiers%% 
%%name  in  use%% 


There  are  EC  data  entities  x  and  y  (not 
necessarily  distinct)  such  that,  if  we  assume 
the  rank  relation  for  data  to  be  transitive, 
both  (x,y)  and  (y,x)  are  in  the  accumulated 
relation. 

The  length  of  the  result  of  a  bitstring 
operation  differs  from  the  length  of  the 
destination  variable. 

An  operation  that  changes  the  value  of  a 
register  has  the  "-SAVE"  suffix. 

An  index  was  provided  as  a  qualifier  for  an 
operand  that  is  not  an  arra<'. 

The  most-significant  bits  are  lost  in  a  real 
to  bitstring  conversion.  This  results  from 
the  user  specifying  a  radix  point  too  close  to 
the  most  significant  bit  in  the  destination 
bitstring. 

The  length  of  a  bitstring  type  exceeds  the 
maximum  allowed. 

The  value  of  a  non-variable  is  greater  in 
magnitude  than  that  allowed  for  an  entity  of 
that  typeclass,  as  given  by  a  system 
generation  parameter. 

A  !+raax  div  result+!  was  given  that  exceeded 
the  I! range! I  of  the  destination  variable. 

More  than  one  qualifier  of  the  same  type  was 
given  for  a  single  operand. 

An  attempt  has  been  made  to  redefine  a  name  of 
one  of  the  following: 

-  a  built-in  object; 

-  an  EC  access  program; 

-  an  EC  UE; 

-  an  EC  reserved  word; 

-  an  EC  system  generation  parameter; 

-  a  user-defined  spectype,  entity, 
array,  region,  or  program. 
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Znonexistent  positionZ 

%range  exceededZ 
ZZrange  too  greatZZ 

ZZranres  too  greatZZ 

! 

%Z res  too  fineZZ 

ZZsubrange  not  aLlowed%% 

[  ZZundeclared  operandZZ 

|  ZZundeclared  spectypeZZ 

ZZunknown  initial  valueZZ 

ZZunknown  operand  in 
attributeZZ 

ZZvariable  parmZZ 


A  user  has  specified  (1)  a  start  position  that 
does  not  exist  in  the  bitstring;  or  (2)  a 
start  position  and  a  length  that  define  a 
substring  not  contained  in  the  bitstring. 

The  value  being  stored  into  a  variable  is 
outside  the  1  '.range!',  of  the  variable. 

The  magnitude  of  the  declared  !!range!! 
exceeds  the  maximum  allowed  for  that 
typeclass,  as  given  by  a  system  generation 
parameter . 

The  ratio  of  the  declared  !!range!!  to  the 
declared  ! Iresolution! !  exceeds  the  maximum 
allowed  for  that  typeclass,  as  given  by  a 
system  generation  parameter. 

Declared  resolution  (or  implied  resolution  of 
a  literal)  was  less  than  the  minimum  allowed 
for  that  typeclass,  as  given  by  a  system 
generation  parameter. 


A  '.'.source!!  ot  '.'.destination!',  is  or  refers 
to  (a)  an  entity  not  declared  previously  using 
++DCL_ENTITY++;  and  (b)  not  an  element  of  a 
previously-declared  array;  and  (c)  not  an  EC 
built-in  object  or  system  generation  parameter. 

The  user  has  supplied  an  undeclared  spectype 
in  an  entity  or  array  declaration,  or  as  the 
attribute  of  a  varying-attribute  variable  or  a 
PTR  spectype. 

A  variable  has  been  used  as  an  initial  value 
of  a  declared  entity. 

An  attribute  has  been  given  using  an  entity 
not  previously  declared  using  ++DCL_ENTITY++ 
as  a  value. 

User  supplied  a  variable  or  loadcon  for  an 
!! actual  parameter!!  when  an  ascon  or  literal 
was  called  for. 


A  subrange  qualifier  was  given  for  a 
non-numeric  operand. 
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S%varying  constants  A  user  sought  to  declare  a  constant  of  a 

specific  type  that  has  varying  attributes. 

t%wrong  init  value  size%Z  The  set  of  initial  values  is  not  the  same  size 

as  the  array. 

•/iwrong  init  value  tvpe%%  A  constant  or  literal  used  as  an  initial  value 

is  not  in  the  domain  of  the  type  of  the  entity 
being  initialized. 


EC. DATA. 6  System  Generation  Parameters 

Parameter  Type  Definition 

#raax  bits  length#  integer  The  maximum  number  of  bits  allowed  for 

a  bitstring. 

#raax  real  ascon#  real  Maximum  allowable  magnitude  for  a  real 

#max  timeint  ascon#  timeint  (timeint)  ascon  or  literal. 

#max  real  loadcon#  real  Maximum  allowable  magnitude  for  a  real 

#max  timeint  loadcon#  timeint  (timeint)  loadcon. 

#max  real  ranres  ratio#  real  Maximum  allowable  magnitude  of  the 

#max  timeint  ranres  timeint  ratio  of  a  type's  llrange!!  to  its 

ratio#  !! resolution! I . 

#max  real  range#  real  Maximum  allowable  magnitude  for  the 

#raax  timeint  range#  timeint  absv(upper  bound  -  lower  bound)  for  a 

real  (timeint)  type. 

#min  real  resolution#  real  Minimum  allowable  resolution  for  a 

#min  timeint  resolution#  timeint  real  (timeint)  entity. 
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EC.IO.l  Introduction 

This  module  implements  two  types  of  bitstring  entities  known  as  input  data 
items  and  output  data  items,  which  are  used  to  communicate  between  the 
computer  and  external  devices.  This  interface  also  includes  facilities  for 
i/o  used  during  channel  diagnostics. 

Each  data  item  may  be  enabled  or  disabled  by  user  programs.  When  enabled, 
communication  with  the  outside  world  is  possible.  The  values  of  input  data 
items  may  be  set  by  external  devices.  The  values  of  output  data  items  are 
transmitted  to  external  devices.  When  a  data  item  is  disabled,  its  connection 
with  the  outside  world  is  severed. 

Although  input  data  items  are  normally  "read-only"  and  output  data  items 
are  normally  "write-only",  a  few  may  be  both  read  and  written  when  they  are 
disabled.  These  may  be  used  as  storage  at  such  times.  An  input  (output)  data 
item  may  always  be  used  as  a  !! source II  ( 1 1 des tination! ! )  in  an  EC  statement. 

User  programs  are  able  to  check  to  see  if  an  external  communication  has 
been  successful. 

Within  these  constraints,  an  input  or  output  data  item  may  be  used  exactly 
as  other  bitstring  variables. 

In  addition  to  the  input  data  items  described  above,  some  input  from  the 
outside  world  is  handled  only  through  semaphores.  For  these  inputs,  which 
correspond  to  transient  events  occurring  in  external  devices,  a  semaphore  is 
incremented  when  the  event  occurs.  There  are  no  corresponding  bitstrings  for 
these  inputs. 


A 
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EC. 10. 2  Interface  Overview 
EC. 10.2.1  Access  programs 

Program  name  Parm  type  Parm  info  Undesired  Events 

♦DISABLE*  pi : dataitem;I  name  of  data  item  ^already  disabled? 

♦ENABLE*  pi : dataitem; I  name  of  data  item  ^already  enabled? 


+G_SUCCESS+  pi: dataitem; I  name  of  data  item  None. 

p2:boolean;0  I  +  i/o  success*! 

Program  effects 


♦ENABLE*  Enables  transmission  to/from  the  external  environment.  If  pi 

is  an  input  data  item,  then  external  values  for  this  input 
item  will  now  become  available  internally  as  soon  as 
practicable.  If  pi  is  an  output  data  item,  the  value  is  now 
available  externally.  If  the  item  is  read-write  input,  use  of 
the  item  as  a  J Idestination! !  in  an  EC  statement  is  now 
prohibited  until  disabled.  If  the  item  is  read-write  output, 
use  of  the  item  as  a  Ilsource!!  in  an  EC  statement  is  now 
prohibited  until  disabled. 

At  system-generation  time,  all  data  items  are  enabled. 

♦DISABLE*  Transmission  to/ from  the  external  environment  will  be 

inhibited.  If  the  item  is  read-write  input,  it  may  now  be 
used  as  a  !  '.destination! '.  in  an  EC  statement.  If  the  item  is 
read-write  output,  it  may  now  be  used  as  a  I! source  1 1  in  an  EC 
statement . 
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SC. 10. 2. 2  Access 

programs  for  10 

diagnostics 

Program  name 

Parm  type 

Parm 

info 

+TEST_AC* 

pl:boolean;0 

+  io 

test 

result+ 

♦TEST  CSA+ 

pi :  boolean;0 

+  io 

test 

result+ 

+TEST  CSB+ 

pi : boolean ;0 

+  io 

test 

result+ 

+TEST  DC* 

pi :  boolean ;0 

+  io 

test 

result+ 

+TEST_DI0W1+ 

pi : boolean ;0 

+  io 

test 

result+ 

♦TEST  DI0W2+ 

pi :boolean;0 

+  io 

test 

result+ 

+TEST_DI0W3+ 

pi  :boolean;0 

+  io 

test 

result* 

+TEST  XACC+ 

pi :boolean;0 

+  io 

test 

result* 

+TEST_YACC+ 

pi  :boolean;0 

+  io 

test 

result* 

+TEST_ZACC* 

pl:boolean;0 

+  io 

test 

result* 

Effect 

s 

Undesired  Events 


None 


These  programs  report  the  results  of  input/output  hardware  diagnostic 
tests.  If  the  test  is  performed  periodically  or  independent  of  user  request, 
the  result  given  will  be  that  of  the  most  recent  test.  If  the  test  is 
performed  on  request,  the  command  will  initiate  the  test  and  report  the  result 
when  the  test  is  complete.  In  addition,  the  following  effects  are  observable. 


+TEST_AC+  This  program  reports  the  results  of  the  AC  signal  converter 

check.  It  may  interfere  with: 


output,  when  the  data  item  is 

//BRGDEST// 
//RNGHND/ / 
//STEERAZ// 


/ /GNDTRK/ / 
//RNGTEN// 
//STEEREL// 


//RNGUNIT// 


♦TEST  CSA+ 


This  program  reports  the  results  of  the  cycle-steal  channel 
A  and  serial  channel  1  check.  It  may  interfere  with: 


output,  when  the  data  item  is 

/ / ASAZ / / 

//ASEL// 

//ASLAZ/ / 

//ASLEL// 

//ASLCOS// 

//ASLSIN// 

//AZRING// 

//BAROHUD// 

//FLTDIRAZ/ / 

//FPMAZ// 

/ /FPMEL/ / 


//HUDCTL/ / 

//LSOLCUAZ// 

/ /LSOLCUEL/ / 

//MAGHDGH// 

//MAPOR// 

//PTCHANG// 

//PUACAZ// 

/ /PUACEL/ / 
//ROLLCOSH// 
// ROLLS INH// 


/ /USOLCUAZ/ / 
//USOLCUEL// 
//VERTVEL// 
//VTVELAC/ / 

/ /XCOMMF / / 
//XCOMMC/ / 
//YCOMM// 


input,  when  the  data  item  is  /LOCKEDON/  or  /SLTRNG/. 
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♦TEST  CSB+ 


♦TEST  DC+ 


+TEST_DI0W1+ 
+TEST_DI0W2+ 
+TEST  DI0W3+ 


+TEST_XACC+ 
+TEST_YACC+ 
+TEST  ZACC+ 


This  program  reports  the  results  of  the  cycle  steal  channel 
B  and  serial  channel  2  check.  It  may  interfere  with: 

output,  when  the  data  item  is 

/ /CURAZCOS/ /  //CURAZSIN//  //CURPOS// 

input,  when  the  data  item  is 

/ANTGOOD/  /DGNDSP/  /DRFTANG/ 

/DRSFUN/  /DRSMEM/  /DRSREL/ 

/ELECGOOD/ 

This  program  reports  the  results  of  the  DC  signal  converter 
check.  It  may  interfere  with: 

output,  when  the  data  item  is 

//FPANGL//  //GNDTRVEL//  //STERROR// 

These  programs  report  the  results  of  the  checks  on  discrete 
input  and  output  word  pairs  1,  2,  and  3  respectively.  These 
programs  may  interfere  with: 

output,  when  the  data  item  is 

/ / DOW 1 / /  // DOW2// 

input,  when  the  data  item  is 

/DIW1/  /DIW2/  /DIW3/ 

/DIW4/  /DIW5/  /DIW6/ 

/ANTGOOD/  /DGNDSP/  /DRFTANG/ 

/DRSFUN/  /DRSMEM/  /DRSREL/ 

/ELECGOOD/  /LOCKEDON/  /SLTRNG/ 

/SINSDD/ 

These  programs  report  the  results  of  checks  on  the 
accelerometer  and  torque  registers  associated  with  the  X,  Y, 
and  Z  axes  of  the  IMS  respectively.  These  programs  may 
cause  the  IMS  to  lose  its  alignment  and  velocities,  and  may 
interfere  with: 

output,  when  the  data  item  is 

/ /XGYCOM//  //YGYCOM/ /  //ZGYCOM// 

input,  when  the  data  item  is 

/XGYCNT/  /XVEL/  /YGYCNT/ 

/YVEL/  /ZGYCNT/  /ZVEL/ 
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SC. 10. 2. 3  Built-in  Objects 

The  names  of  3ll  data  items  are  listed  in  Appendix  5  of  this 

Undesired  Events  associated  with  Built-in  Obj e c t s 

The  following  undesired  events  may  occur  when  data  items  are  used 
statements : 

%read-write  violation% 
%%read/write-only  violation^ 


document . 


in  EC 


EC. 10. 2. 4  Events  signalled  by  incrementing  a  semaphore 

For  some  inputs,  an  event  is  signalled  (by  incrementing  a  semaphore) 
when  a  new  value  of  an  input  data  item  has  been  transmitted.  The  event  is  of 
the  form 

@T(  1+  x  ready+l ) 

where  "x"  is  the  name  of  the  data  item. 

Some  inputs  correspond  to  an  event  occurring  in  an  external  device. 

•Vhen  such  an  event  occurs,  this  module  will  signal  a  corresponding  event  of 
the  form 

@T(!+  x  occurred) 

where  "x"  specifies  the  event. 


These  events  and  their  corresponding  semaphores  are  enumerated  in 
Appendix  5. 


A 


I 


» 


EC. 10. 3  Local  Type  Definitions 


dataitem 


The  name  of  any  input  or  output  data  item.  The  data 
items  are  listed  in  Appendix  5  of  this  document.  The 
semantics  of  the  data  items  are  given  in  Chapter  2  of 
[REQ]. 
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EC. 10.4  Dictionary 
Term 

Any  item  of  the  form 
1+  x  ready+I 


Any  item  of  the  form 
1  +  x  occurred+I 


!+i/o  success+! 


I+io  test  result+! 


Definition 


The  named  data  item  is  now  available  for  read 
operations . 

The  named  event  has  just  occurred  in  an 
external  device. 

true  iff  the  last  transmission  associated  with 
the  named  data  item  was  successful. 

true  iff  the  i/o  hardware  passes  built-in  test. 


EC. 10. 5  Undesired  Event  Dictionary 


^already  disabled% 


A  user  program  has  tried  to  disable  a  data  item 
already  disabled. 


^already  enabled% 


A  user  program  has  tried  to  enable  a  data  item 
already  enabled. 


ZZt ead / wr i t e-on 1 y 
violation%% 


A  read-only  Cwrite-only)  data  item  appears 
as  a  I! destination I I  ( ! I  source  I I ). 


%read-write  violation!? 


A  program  call  was  executed  with  a  read-write 
input  (output)  data  item  as  a  I  Idestination! I 
("source II)  when  that  data  item  was  enabled. 


EC. 10. 6  System-Generation  Parameters 

Parameter  Type  Explanation 

#max  i/o  time  x#  timeint  (where  "x"  is  replaced  by  the  name  of 

each  data  item)  The  maximum  time 
interval  that  can  elapse  between  the 
beginning  of  the  access  program  that 
reads/writes  the  named  item,  and  the 
time  it  takes  for  the  external 
transmission  to  take  place. 


#nbr  fltrec  elements#  integer  Defined  in  Appendix  5. 


. 


EC. MEM 

Virtual  Memory  Module 


EC. MEM. 1  Introduction 

This  module  provides  a  uniformly  addressable  memory  for  the  Extended 
Computer,  as  well  as  hiding  the  particular  addresses  to  which  data  and 
instructions  are  allocated. 

The  only  part  of  the  interface  that  is  not  hidden  from  EC  programmers 
(who  do  not  need  to  use  it)  is  that  which  reports  to  the  user  the  results  of  a 
diagnostic  test  on  the  memory  hardware.  The  specifications  for  the  remainder 
of  the  module  appear  in  [VM] . 

EC. MEM. 2  Interface  Overview 


EC. MEM. 2.1  Memory 

diagnostic  access 

programs 

Program  name 

Parm  type 

parm  info 

Undesired  Events 

♦TEST  MEMORY + 

pi :  boolean; 0 

!+memory  test  result+! 

None 

Effects 

Reports  the  result  of  the  memory  diagnostic  test.  If  the  test  is 
performed  periodically  or  independent  of  user  request,  the  result  given  will 
be  that  of  the  most  recent  test.  If  the  test  is  performed  on  request,  the 
command  will  initiate  the  test  and  report  the  result  when  the  test  is  complete 


EC. MEM. 3  Local  Type  Definitions:  None. 

EC .MEM. 4  Dictionary 

I+memory  test  result* J  true  iff  the  memory  diagnostic  test  is 

passed. 


EC. MEM. 5  Undesired  Event  Dictionary:  None. 
EC. MEM. 6  System  Generation  Parameters:  None. 
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PROCESS  MECHANISMS 


EC. PAR. 1.1  Introduce  ion 

The  process  mechanism  allows  the  definition  of  a  set  of  sequential 
processes  that  will  proceed  in  parallel  and  unknown  relative  speeds.  Demand 
processes  are  activated  when  specific  events  occur.  Periodic  processes  may  be 
turned  on  or  off,  but  are  re-started  at  regular  intervals  when  turned  on. 

EC. PAR. 1.2  Interface  Overview 


EC. PAR. 1.2.1  Access  program  table 


Program  name 


++D  PROCESS++ 


Parm  type 


pi: timeint  ;I 
p2: invocation;! 


Parm  info 

l+deadline+'. 
process  body 


Undesired  events 

%inconsistent 
time  parms% 

%% undeclared 
program%% 
%?variable  timing 
parms%% 


++P  PROCESS++ 


pi : timeint ; I 
p2 : timeint ; I 
p3: semaphore; I 
p4: invocation; I 
p5: boolean; I 


! +deadline+I 
!+period+! 

! +starting  event+1 
process  body 
'.+on/off+i 


%inconsistent 
time  parms% 
%%illegal  synch%% 
%%undeclared 
program%% 
%missed  deadline? 
%%variable  timing 
parms%% 
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Program  effects 

++D_PROCESS++  establishes  a  demand  process  that  becomes  active  after 

@T(i+power  up+1).  The  body  of  the  process  is  the  program 
named  by  p3.  The  process  remains  active  until  it  is 
suspended  as  a  result  of  a  synchronization  operation  (see 
EC. PAR. 2,  EC. PAR. 2)  or  executes  the  last  statement  in  its 
body.  During  the  interval  when  it  is  active,  it  will 
execute  before  p2  real  time  has  elapsed.  A  process  that  is 
suspended  as  a  result  of  a  synchronization  operation  may 
start  again.  A  process  that  executes  its  last  statement 
will  start  again  only  after  a  system  generation. 

++P_PROCESS++  establishes  a  periodic  process  that  becomes  active  after  the 
semaphore  named  by  !+starting  event* !  becomes  nonnegative. 
The  body  of  the  process  is  the  program  named  by  p5.  While 
the  boolean  named  by  p6  is  true,  a  built  in  semaphore,  NEXT 
PERIOD,  will  be  incremented  at  the  start  of  each  !+period+! 
amount  of  real  time.  After  the  start  of  a  !+period+!,  the 
process  will  complete  exeuction  before  p2  real  time  has 
elapsed.  The  process  must  perform  [+DOWN+,NEXT_PERIOD] 

[ +PASS+ , NEXT_PERIOD] . 

If  p6  is  given  as  a  variable,  and  that  variable  becomes 
false  during  execution,  the  process  will  stop  when  it  waits 
for  the  start  of  its  next  !+period+!  (by  invoking 
[  *P  ASS* ,  NEXT_PERIOD )). 

If  p3  is  given  as  a  variable,  and  that  variable  changes 
value  during  execution,  the  pro<  'f  3  will  change  its 
!+period+!  within  an  amount  of  time  equal  to  the  previous 
value  of  p3. 

Both  If  two  (or  more)  processes  simultaneously  execute  sequences 

of  statements  that  read  and/or  alter  the  value  of  some  data, 
the  results  are  unpredictable  because  the  executions  may 
overlap  in  time.  However,  EC  access  programs  are  considered 
indivisible.  If  two  EC  access  programs  are  executed 
simultaneously  by  two  processes,  the  effect  will  be  as  if 
one  of  the  processes  executed  its  access  program  before  the 
other;  the  order  is  not  specified.  Note  that  the  invocation 
of  a  user-supplied  routine  is  the  execution  of  a  single  EC 
access  program,  but  the  execution  of  the  body  of  that 
routine  is  a  sequence  of  EC  statements. 
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Program  effects  (continued) 

+TEST_INTERRUPTS+  Reports  the  results  of  the  interrupt  hardware  checks.  If 

the  test  is  performed  periodically  or  independent  of  user 
request,  the  result  given  will  be  that  of  the  most  recent 
test.  If  the  test  is  performed  on  request,  the  command 
will  initiate  the  test  and  report  the  result  when  the  test 
is  complete.  It  may  interfere  with  normal  operation  of 
timers  and  input/output  commands  in  unpredictable  ways. 


EC. PAR. 1.2.2  Built-in  objects 
Name  Used  to  Refer  to 

NEXTJERIOD  semaphore  variable,  private  to  each  periodic  process,  that 

will  be  incremented  by  the  EC  at  the  start  of  each  period. 
Each  periodic  process  only  has  access  to  its  own 
NEXT_PERIOD.  Semaphores  are  described  in  EC.SMPH. 


EC. PAR. 1.3  Local  Type  Definitions 


invocation 


An  occurrence  of  a  program  invocation,  as  described 
in  EC. PGM. 3. 2. 


EC. PAR. 1.4  Dictionary 


Term 

J+deadline+! 


I+interrupt  test 
result+ ! 


Definition 


The  maximum  amount  of  real-time  that  can  be  allowed 
to  elapse  between  the  time  that  a  process  can 
proceed  and  the  time  that  it  reaches  the  next  point 
of  suspension. 

true  iff  the  interrupt  hardware  passes  built-in  test. 


I+on/off+i  the  boolean  whose  value  will  be  used  to  start/stop 

the  periodic  process  in  whose  definition  it 
appears.  Its  value  must  be  $true$  whenever  the 
periodic  process  is  supposed  to  proceed.  If  it  is 
fcfalsefc  when  the  process  next  reaches  its  starting 
point,  the  process  will  be  suspended  until  it 
becomes  $true$  again.  Of  course,  the  value  may  only 
be  changed  if  the  boolean  was  given  as  a  variable. 
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.  +period+!  The  ti.mei.nt  whose  value  will  be  interpreted  as 

the  amount  of  real-time  that  should  elapse 
between  the  beginning  of  one  execution  of  a 
periodic  process  and  the  beginning  of  the  next 
execution.  If  i+period+!  is  given  as  a  variable, 
changing  its  value  has  the  result  of  changing  the 
period  of  any  process  for  which  it  was  used  as 
the  i+period+I. 

•♦starting  event+!  The  name  of  a  semaphore  that,  when  becoming 

nonnegative,  will  cause  the  periodic  process  in 
which  it  is  named  to  become  active. 

EC. PAR. 1.5  Undesired  Event  Dictionary 

ZZillegal  synch%Z  a  synchronization  operation  other  than  the 

required  +DOWN+(NEXT  PERIOD)  and 
+PASS+(NEXT_PERIOD)  ?see  EC.SMPH)  appears  in  the 
body  of  a  periodic  process;  or  those  required 
operations  were  omitted. 

the  timing  parameters  are  contradictory;  e.g. 
!+max  CPU  time  req+!  exceeds  I+deadline+! ,  or 
!+deadline+!  exceeds  the  current  value  of 
1 +period+! . 

Zmissed  deadlineZ  a  process  has  missed  its  deadline  because  too 

many  demand  processes  have  occurred,  or  because 
its  I+deadline+I  was  less  than  the  CPU  time 
required  for  it  to  execute. 

ZZvariable  timing  J+deadline+I  or  !+max  CPU  time  req+I  was  given 

parms%%  using  a  variable  or  a  loadcon. 


EC. PAR. 1.6  System  Generation  Parameters:  None 
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EXCLUSION  REGIONS 

EC. PAR. 2.1  Introduction 

This  module  allows  constraints  to  be  placed  on  the  potential  concurrency 
of  processes  executing  regions  of  code  by  defining  an  exclusion  relation  among 
them.  Region  1  exc ludes  region  2  if  starting  to  execute  region  2  is  forbidden 
while  region  1  is  being  executed.  Mutual  exclusion  is  a  special  case  of  this 
exclusion  relation,  which  is  based  on  [BELP73]. 


EC. PAR. 2. 2 
EC. PAR. 2. 2. I 
Program  name 
++REGION++ 


Interface  Overview 

Access  program  table 

Parm  type 

p 1 : name ; I 

p2 : statement-list 


;i 


Parm  info  Undesired  events 

region  name  %%name  in  use%% 

region  body 


++EXCLUSION++  pi : exclusion-relation; I 


%%undeclared 

region%% 


++EXCLUSION++ 


++REGION++ 


Effects  , 

If  the  exclusion  relation  includes  (A,B)  then  no  process 
will  begin  to  execute  region  B  in  the  interval  that  starts 
when  a  process  begins  execution  of  region  A  and  ends  when 
that  process  completes  execution  of  region  A.  The 

exclusion  relation  for  all  regions  is  composed  of  the  < 

exclusion  relation  given  in  each  invocation  of  this  program. 

pi  may  be  used  to  stand  for  the  section  of  code  that  is 
given  in  p2.  If  the  last  action  before  the  region  causes  a 
process  to  wait,  then  the  process  is  considered  to  be 

inside  the  region  when  it  is  allowed  to  proceed.  If  the  i 

last  statement  in  p2  is  a  wait  operation,  then  the  process 

is  considered  to  have  left  the  region  when  it  begins  to 

wait.  Including  regions  in  a  process  will  prevent  the 

process  from  waking  up,  if  doing  so  would  result  in  a 

violation  of  an  exclusion  region. 
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EC. PAR. 2. 3  Local  Type  Definitions: 

exclusion-relation  A  Ilrelation!!  on  region  names, 

statement-list  A  sequence  of  1 Icommand! Is. 

EC. PAR. 2.4  Dictionary:  None 

EC. PAR. 2.5  Undesired  Event  Dictionary 

%%undeclared  region%%  an  exclusion  relation  includes  regions  that  have 

not  been  identified  in  the  program. 

EC. PAR. 2. 6  System  Generation  Parameters:  None 
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PROGRAM  CONSTRUCTION 

EC. PGM. 1. I  Introduct ion 

Using  the  facilities  of  this  module,  a  user  can  construct  programs 
composed  of  invocations  of  EC  built-in  access  programs  and  user-defined 
programs.  This  is  done  by  naming  the  entrances  and  exits  of  these  programs 
and  describing  connections  between  them.  Each  exit  is  connect  to  one 
entrance.  The  resulting  structure  is  called  a  .'! constructed  program!  ! .  On 
completion  of  its  execution,  a  program  selects  an  exit;  the  next  program 
executed  will  begin  execution  at  the  entrance  connected  to  that  exit. 

All  EC  access  programs  have  one  entrance.  Many  have  one  exit,  but  some 
(see  EC. PGM. 1 . 2. 1 )  have  as  many  exits  as  there  are  values  in  the  range  of  the 
output  parameter.  When  such  a  program  is  executed,  it  chooses  the  exit  that 
corresponds  to  the  value  it  has  computed. 

A  !!  constructed  program.'!  is  a  literal  of  the  typeclass  PGM.  In  EC. PGM.  2 
we  describe  the  declaration  and  use  of  entities  of  that  typeclass.  In 
EC. PGM. 3  we  describe  facilities  for  invoking  programs  as  closed  subroutines. 

EC. PGM. 1.2  Interface  Overview 

EC. PGM. 1.2.1  Entrances  ~ and  exits  of  *EC -access -programs 
Every  EC  access  program  has  exactly  one  entrance. 

Every  EC  access  program  that  has  a  single  output  parameter  has  n  exits, 
where  n  is  the  number  of  values  that  can  be  computed  for  the  output 
parameter.  The  exits  are  named  Ev,  where  "v"  is  replaced  by  the  literal 
representation  of  the  value  (except  that  is  replaced  by  "m").  For 

example,  an  exit  corresponding  to  the  real  -32.7  is  named  Em32.7.  If  the 
value  computed  is  a  bitstring  of  length  1,  the  exits  can  be  Etrue  and  Efalse. 
If  a  program  computes  a  value  u  as  its  result,  it  takes  exit  Eu. 

All  other  EC  access  programs  have  exactly  one  exit. 
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EC.  PGM.  1.2.2  Entrances  and  exits  of-.1  Icons  true  ted  'program.1  Is 

Program  name  Parm  type  Parm  info  Undesired  events 

++ENTRANCE++  pi : name- 1  is t ; I  entrance  name(s)  ?%duplicate  name£% 

%%port  not  defined%% 
%%port  defined  twice%% 
%%no  such  entrance%% 


++EXIT++  pi : name-lis t ; I  exit  name(s) 


%%duplicate  name%% 
%%port  not  defined%% 
%%port  defined  twice%% 


Parameters 


Each  name  in  pi  of  ++ENTRANCE++  must  be  an  entrance  to  a  ! [command! I  in 
the  !! constructed  program!!. 


Effects 


++ENTRANCE++  Defines  the  given  name(s)  as  entrance(s)  to  the  !! constructed 
program!!  in  which  they  appear.  The  name(s)  may  be  used  when 
the  !! constructed  program!!  in  which  this  I ! invocation! !  appears 
is  invoked  (see  EC. PGM. 3). 

++EXIT++  Defines  the  given  name(s)  as  exit(s)  to  the  !! constructed 

program!!  in  which  they  appear.  An  exit  of  a  !!command!!  in  the 
same  !! constructed  program!!  may  be  connected  to  one  of  these 
exits  as  specified  in  EC. PGM. 1.2. 3;  i.e.,  %%not  an  exitX%  is 
disabled  for  the  given  names  in  this  .'[constructed  program!!. 


exit-connector  :  :  =  (  exit-list  :  label  ,  ,  exit-li3t  •  label  11 

OR  :  label 
OR 


The  second  form  of  the  exit-connector  is  an  abbreviation 
that  is  equivalent  to  pairing  all  exits  }f  the  orogram 
with  the  same  label.  The  third  (null'  form  is  equivalent 
to  ":L  L:"  where  L  is  some  name  not  used  anvwhere  else. 

exit-list  : :=  exit 

OR  (  exit,  exit,  ...,  exit  ) 

OR  (  Em  :  En  ) 

The  third  form  is  equivalent  shorthand  for  (Em,  Em+1 , 
Em+2,  . ..,  En-l,  En)  where  m  and  n  are  Integer  literals, 
not  greater  than  n. 

exit  ::=  name  (naming  an  exit  of  the  11  command) 1) 

label  : : =  name  (naming  a  label  of  any  llcommandll  in  the 

1 1  constructed  program!!  in  which  this 
llcommandll  appears;  or  naming  an  exit  of 
the  1 1  constructed  program! 1  in  which  this 
llcommandll  appears. 

After  a  llcommandll  is  executed,  the  next  llcommandll  to  be  executed  will 
be  the  one  whose  label  is  paired  in  the  exit-connector  with  the  exit  that 
the  llcommandll  selected. 

%%dest  unknown%% 

%%illegal  exit-list%% 

%nowhere  to  go% 

£%not  an  exit%% 


These  UEs  apply  to  exit-connectors: 
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EC.PGM.1.3  Local  Type  Definitions 

name-list  A  I! list!!  of  names. 


EC. PGM. 1.4  Dictionary 

! '.command! '.  An  !!  invocation!  I  ,  preceded  by  a  label-list,  and 

suffixed  by  an  exit-connector. 

!  !constructed  program.'!  A  sequence  of  I Icoramand! ! s ,  beginning  with  one 

!! invocation! !  of  ++ENTRANCE++  and  ending  with 
one  invocation  of  ++EXIT++  specifying  the 
entrances/exits  to  the  sequence  considered  as  a 
whole.  No  other  invocations  of  ++ENTRANCE++  or 
++EXIT++  may  appear. 

!! invocation ! !  A  program  invocation,  as  defined  in  section 

EC. PGM. 3. 


EC. PGM. 1.5  Hndesired  Event  -Dictionary 

%%dest  unknown%%  An  exit-dest  in  an  exit-connector  was  neither  (a) 

a  label  preceding  any  other  !.' command .' !  in  the 
! Iconstructed  program!!;  nor  (b)  the  name  of  an 
exit  to  the  !! constructed  program!!. 

%%duplicate  name%%  A  name  appeared  twice  in  the  same  list. 

%%illegal  exit-list%%  An  exit-list  of  a  !!command!!  either  (a)  names 

the  same  exit  twice;  or  (b)  is  of  the  form 
(Era:En)  and  m  is  greater  than  n. 

%%no  such  entrance%%  The  name  given  as  the  entrance  of  a  ! Constructed 

program!!  is  not  used  as  a  label  preceding  any 
Ilcommand!!  in  the  ! Iconstructed  program!!. 
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VL not  an  exit.?%  The  exit-connector  contained  an  exit  that  is  not 

an  exit  of  the  program  being  invoked. 

"nowhere  to  go%  A  program  took  an  exit  that  was  left  unconnected. 

’!%port  defined  twice%%  A  ! ! cons tructed  program!!  contained  more  than  one 

.' !  invoca t  ion ! !  of  ++ENTRANCE++  or  ++EYTT++. 

?%port  not  defined%%  A  !! constructed  program! I  did  not  contain  an 

!!  invocation!  !  of  «--i-ENTRANCE++,  or  did  not 
contain  an  ! I  invocation! I  of  ++EXIT++. 


EC. PGM. 1.6  Sys tem  Generation -Parameters :  None. 
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EC. PGM. 2 

PROGRAM  ENTITIES 


This  module  provides  mechanisms  for  declaring  entities  of  type  program  and 
assigning  a  value  to  them.  The  EC  access  programs  are  built-in  program 
constants;  see  EC. PGM. 2 . 2 . 3 . 2 . 

EC. PGM. 2. 2  Interface  Overview 


EC.PGM.2.2.1  Declaring  a  Program  type 

To  declare  specific  program  types,  use  the  ++DCLj_TYPE++  program  specified 
in  EC. DATA. 2.1,  with: 

p2  =  PGM; 

p3  a  pgm-attr ibute ,  defined  in  section  EC. PGM. 2. 3; 
and  the  other  parameters  as  described  there. 


EC. PGM. 2. 2. 2  Creating  -a  -Program 

To  create  an  entity  of  the  program  typeclass,  use  ++DCL*ENTITY++  (see 
Section  EC . DATA. 2 . 2 . 1 )  with: 

p2  =  a  program  spectype  (builtin  or  user-declared); 
p4  =  a  program  literal,  or  a  parameter less  program  constant 
of  spectype  p2 ; 

and  the  other  parameters  as  described  there. 


To  create  an  array  of  program  entities,  use  ++DCL_A>}RAY++  (see  Section 
SC. DATA. 2. 2. 2)  with: 

p2  =  a  program  spectype  (builtin  or  user-declared); 
p4  =  an  array-init  (defined  in  EC. DATA. 2. 3)  of  program 
literals  or  parameter less  program  constants  of 
spectype  p2; 

and  the  other  parameters  as  described  there. 


j 

% 
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EC. PGM. 2. 2. 2 

Other  Operations 

onProgram  Entities 

Program 

Farm- type 

Farm • in  fo 

Undesired -events 

++RANK_PGM++ 

pi : rank-pgm- 

%%incons is  tent  ogm 

relation;! 

ranking*^ 

+SET+ 

++SET++ 


pi : program; I 
p2 : program;0 


! +source+! 

! +des  tinacion+ ! 


^inconsistent  Dgms%% 


Parame  ters 


+SET+ 

++SET++ 


pi  and  p2  must  be  program  entities  having  the  same  attributes. 
Neither  may  have  parameters. 


Program "Effects 


++RANK  PGM++ 


Let  A  and  B  be  program  entities  previously  declared  using 
++DCL_ENTITY++ ,  or  arrays  of  program  entities  previously 
declared  using  ++DCL_ARRAY++.  If  (A, B)  appears  in  the 
rank-pgm-relation  for  this  invocation  of  the  program,  then  the 
time  it  takes  to  invoke  A  will  be  no  longer  than  the  time  it 
takes  to  invoke  B  in  the  same  program.  (If  A  (B)  is  an  array, 
then  read  "all  program  entities  in  A  (B)".)  The  rank  relation 
for  all  user-defined  program  entities  is  the  union  of  the 
rank-pgm-relations  given  in  each  invocation  of  this  program. 
The  relation  is  transitive,  antireflexive,  and  antisymmetric. 


+SET+ 

++SET++ 


As  described  in  EC. DATA. 2.5. 


EC.PGM.2.2.3  Buil t-in  Ob jects 
EC.PGM.2.2.3.1  Undesired -Event -Programs 


Every  run-time  UE  specified  in  this  document  is  a  built-in  uninitialized 
program  variable,  which  will  be  invoked  when  the  error  condition  corresponding 
to  the  UE  definition  is  detected  by  the  EC  program(s)  to  which  the  UE 
applies.  It  is  up  to  the  user  to  assign  a  value  to  each  of  these  variables; 
if  one  of  these  variables  remains  uninitialized  at  the  time  of  its  invocation 
by  an  EC  access  program,  the  UE  ^uninitialized  pgm%  is  raised.  The  variables 
are  of  the  builtin  spectype  El. 


For  every  run-time  UE  Zx%  defined  in  this  document,  there  is  a  built-in 
boolean  variable  Bx  with  the  following  properties: 

(a)  its  initial  value  is  $true$; 

it  may  not  be  used  as  a  .'  !  sour ce .'  I  ; 

it  may  only  be  used  as  a  .' ! des  tination ! !  in  the  ++SET++  program; 
hence,  ++SET++  is  the  only  way  its  value  may  be  changed, 
the  EC  will  check  for  %x%  only  in  code  segments  for  which  Bx  is 

$true$ . 

51 
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EC. PGM. 2 


EC. PGM. 2. 2. 3. 2  EC  Built-in  Access  Programs 

Each  EC  access  program  is  a  built-in  constant  of  the  program  typeclass. 
For  most  programs,  the  spectvpe  of  the  program  is  not  named.  If  the  access 
program  has  no  parameters,  its  spectvpe  is  El. 


EC.PGM.2.3  Local  Type  Definitions 


El  A  built-in  specific  type  of  the  program  typeclass.  It  is 

characterized  by  a  single  entrance  named  ENTRANCEl  and  a 
single  exit  named  EXIT1. 


pgm-attribute  An  ordered  pair  (  .'.'list.'!  ,  .'Hist'!  ).  The  first 

"list”  names  the  entrance (s)  to  programs  of  the  type; 
the  second  "list."  names  the  exit(s)  of  programs  of  the 
type. 


program 


rank-pgm- 

relation 


An  entity  of  the  program  typeclass  previously  declared  via 
++DCL_ENTITY++ ,  or  a  member  of  a  program  array  previously 
declared  via  ++DCL_ARRAY++ ,  or  a  built-in  EC  access 
program,  or  a  program  literal.  A  program  literal  is  a 
"constructed  program!!  as  defined  in  section  EC.PGM.l. 

A  ."relation."  of  user-declared  program  entities. 


EC. PGM. 2.4  Dictionary:  None. 


EC. PGM. 2. 5  Hndesired  Event  Dictionary 


%% inconsistent  pgms%% 


%%inconsistent  pgm 
ranking%% 


An  assignment  was  attempted  between  entities 
of  different  attributes;  or,  one  of  the 
entities  is  not  a  parameterless  program. 

There  are  user-declared  program  entities  x 
and  y  (not  necessarily  distinct)  such  that, 
given  the  transitivity  of  the  rank  relation 
for  programs,  both  (x,y)  and  (y,x)  are  in  the 
relation. 


%uninitialized  pgm%  An  undesired  event  program  variable  has  been 

invoked  by  an  EC  program,  but  that  program 
was  never  given  a  value  by  the  user. 


EC. PGM. 2.6  System -Generation- Parameters:  None 
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EC. PGM. 3 

PROGRAM  INVOCATION  FACILITIES 

EC. PGM. 3.1  Introduction 

This  module  provides  mechanisms  for  invoking  programs  (either  built-in  or 
user-defined)  as  closed  subroutines  and,  in  the  former  case,  passing 
parameters  to  those  programs. 


Effects 

If  an  EC  run-time  access  program  is  named,  the  effect  is  that  which  is 
specified  for  that  program.  If  an  EC  system-generation-time  access 
program  is  named,  there  is  no  run-time  effect.  If  a  user-defined  program 
is  named,  the  effect  is  that  of  executing  the  run-time  .' I  command!  Is  in  the 
'.'constructed  program!!  that  has  been  assigned  to  the  program  (either  as 
the  initial  value  as  described  in  EC. PGM. 2. 2. I ,  or  subsequently  as 
described  in  EC. PGM. 2. 2. 3)  beginning  at  the  entrance  named. 


Undes ired • events 

The  following  undesired  events  apply  to  program  invocation: 

%%constant  destination%% 

%%entrance  incorrectly  omitted%% 

%%not  an  entranced 
%%parm  wrong  type%% 

^recursive  call% 
tttoo  few  parms%% 

%%too  many  parms%% 

%%undeclared  program%% 
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EC.PGM.3.3  Local  Type  Definitions 


entrance 


para-list 


parm 


The  name  of  an  entrance  to  the  program  that  is 
the  value  of  the  invoked  entity,  previously 
specified  by  ++ENTRANCE++  for  that  program. 


OR  ,  parm  parm-list 
An  ! lactual  parameter!!  to  the  program. 


Pgm  ::=  program 

OR  (  program  ,  entrance  ) 

The  first  form  may  be  used  when  the  program 
only  has  one  entrance. 


EC. PGM. 3.4  Dictionary 

. lactual  parameter!!  An  entity  that  appears  in  the  parameter  list 

of  a  program  invocation.  The  forms  that  this 
may  take  are  specified  in  EC. DATA. 2.4. 


EC. PGM. 3.5  Undesired  Event  Dictionary 

%%constant  destination%%  The  user  has  supplied  a  constant  or  a  literal 

as  a  ! Idestination! ! . 


%%entrance  incorrectly 
omitted%% 


The  user  has  filed  to  specify  an  entrance  in 
an  invocation  of  a  program  that  has  more  than 
one  entrance. 


%7o not  an  entrance%% 
%%parm  wrong  type%Z 


%recursive  call% 


%%too  few  parms%% 
%%too  many  parms%% 

%%undeclared  program%% 


The  entrance  named  in  the  invocation  is  not  an 
entrance  to  the  program  being  invoked. 

The  type  of  an  I lactual  parameter!!  is  not  of 
the  type  called  for  in  the  specification  of 
the  program. 

A  program  has  invoked  itself,  either  directly, 
or  indirectly  through  an  invocation  of  a 
program  variable. 

The  programmer  supplied  a  different  number 
of  !! actual  parameters!',  than  the  number 
called  for  by  the  program's  specification. 

Program  called  or  referenced  is  neither  an  EC 
access  program  nor  a  program  declared  by  the 
user. 


EC. PGM. 3.6  System  Generation  Parameters:  None 


EC.SMPH 

SYNCHRONIZATION  VARIABLES  AND  OPERATIONS 


EC.SMPH. 1  Introduction 

This  module  provides  a  run-time  synchronization  mechanism,  semaphores, 
with  associated  operations.  They  can  be  used  where  exclusion  regions  cannot 
express  the  constraints.  This  mechanism  is  based  on  [BELP73];  the  semaphore 
operations  are  a  more  primitive  version  of  Dijkstra's  P  and  V  [DIJK68]. 

Semaphores  can  also  be  affected  by  timers;  see  EC. TIMER. 


EC.SMPH. 2  Interface  Overview 

EC.SMPH. 2. I  Creating  a  Semaphore 

To  create  specific  semaphore  types,  use  the  ++DCL_TYPE++  program 
specified  in  EC. DATA. 2,  with: 

p2  »  SEMAPHORE; 

p3  a  semaphore-attribute,  defined  in  EC.SMPH. 3; 
and  the  other  parameters  as  described  there. 

Semaphore  entities  must  be  declared  before  they  can  be  used.  Use  the 
++DCL_ENTITY++  program  of  Section  EC. DATA. 2. 2,  with: 

p4  (the  initial  value)  given  as  an  integer  literal; 
and  the  other  parameters  as  described  there. 

To  create  an  array  of  semaphores,  use  the  ++DCL_ARRAY++  program  of 
EC. DATA. 2. 2. 2,  with: 

p4  as  described  there,  with  initial  values  given  as 
integer  literals; 

and  the  other  parameters  as  described  there. 
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EC.SMPH.2.2  Access  programs 

Program  name  Parm  type  Parm  Info  Undesired  Events 

+DOWN+  pi : semaphore ; 10  Grange  exceeded% 

+UP+ 

+SET+  pi : semaphore ; I 

p2: semaphore ;0 


+PASS+  pi : semaphore ; I  None. 

Program  effects 

In  this  section,  we  characterize  informally  the  effects  of  the 
synchronization  operations.  For  a  more  precise  description,  see  the  formal 
specifications  in  [TRACE].  MState( self )"  means  the  state  of  the  process  in 
which  the  synchronization  operation  appears. 

Terminology: 

Term  Explanation 

state  Either  "active"  or  "suspended". 

state(self)  the  state  of  the  process  executing  the  operation 

state(waiters)  the  state  of  all  processes  in  the  middle  of  a  +PASS+ 


operation  for  that 

semaphore 

Effect  on  the  integer 

Operation 

equivalent  of  the 

Effect  on  process  state(s) 

named  semaphore 

+UP+ 

incremented  by  1 

if  the  semaphore  gteq  0  then 
state(waiters)  :*  active* 

+PASS+ 

none 

if  the  semaphore  It  0  then 
state(self)  :=  waiting 

+DOWN+ 

decremented  by  1 

none 

+SET+ 

p2  set  to  value  of  pi 

same  as  if  the  value  of  p2  were 

arrived  at  by  the  smallest  possible 
number  of  consecutive  operations  of 
+UP+  and  +D0WN+. 

*  a  change  in  "state(waiters)"  means  that  all  the  other  processes  in 
pending  +PASS+  operations  on  that  semaphore  may  be  made  active  in  an 
unspecified  order.  A  process  that  becomes  active  may  make  the  semaphore 
negative,  causing  any  other  processes  in  the  midst  of  a  +PASS+  to  remain  in 
the  waiting  state.  Processes  will  be  activated  and  complete  the  pass  as  long 
as  the  semaphore  is  nonnegative. 
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EC.SMPH. 3  Local  Type  Definitions 

semaphore  A  run-time  synchronization  object  created 

previously  by  a  user  program  by  calling  ++DCL 
ENTITY++;  or  one  of  the  EC’s  built-in  semaphores 
listed  in  EC. INDEX. 

semaphore-attribute  An  ordered  pair  of  integers  specifying  the  lower 

bound  and  upper  bound  of  the  type. 


EC. SMPH. 4  Local  dictionary:  None 
EC.SMPH. 5  Undesired  Event  Dictionary:  None 


EC. SMPH. 6  System  Generation  Parameters 

Parameter  Type  Definition 

#raax  semaphore  ascon#  semaphore  Maximum  allowable  magnitude  for  a 

semaphore  ascon  or  literal. 

#max  semaphore  loadcon#  semaphore  Maximum  allowable  magnitude  for  a 

semaphore  loadcon. 

#ra ax  semaphore  range#  semaphore  Maximum  allowable  value  for 

absv(upper  bound  -  lower  bound)  for 
a  semaphore  type. 
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EC . STATE 

EXTENDED  COMPUTER  STATE 


EC. STATE. 1  Introduction 

This  module  controls  and  reports  transitions  between  Extended  Computer 
states. 


EC. STATE. 2  Interface  Overview 
EC . STATE .2.1  Access  programs 
Program  name  Parm  type 


Parm  info 


Undesired  Events 


+S  FAIL  STATE + 


EC. STATE. 2. 2  Events  signalled  by  incrementing  a  semaphore 


Event 

^TTT+powe  r  up+ ! ) 

@T( ! +f ailed  state+I) 


Semaphore  incremented  when  event  occurs 
ECPOWUP  ~ 
ECFAILED 


+S  FAIL  STATE+ 


@T(!+failed  state+!) 


@T(!+power  up+I) 


Program  and  Event  effects 

The  Extended  computer  enters  its  failed  state, 
increments  ECFAILED,  and  executes  an  internal 
shutdown  procedure. 

Programmers  should  assume  that  when  #close  down  time# 
has  elapsed  after  this  event,  no  more  software 
actions  can  occur. 

The  Extended  Computer  has  entered  the  operating  state 
and  is  functioning  correctly.  All  demand  processes 
are  started. 


EC. STATE. 3  Local  Type  Definitions:  None. 
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EC. STATE. 4  Dictionary 
Term 

!+power  up+! 


Definition 

computer  is  in  the  operating  state  and  may  be 
assumed  to  be  functioning  properly. 


l+failed  state+1 


computer  is  malfunctioning. 


EC . STATE . 5  Undesired  Event  Dictionary:  None . 


EC . STATE . 6  System  Generation  Parameters: 

Parameter  Type  Explanation 

#close  down  time#  timeint  The  minimum  expected  time  interval  between 

the  moment  that  the  extended  computer 
enters  failed  state  and  the  moment  when  no 
more  software  actions  may  occur. 


EC. TIMER 
TIMER  FACILITIES 


EC. TIMER. 1  Introduction 

This  module  provides  facilities  for  measuring  real  time  intervals  via 
timers.  A  timer  is  a  tiraeint  variable  that,  when  running,  will  increment  or 
decrement  at  a  rate  commensurate  with  real  time. 

A  timer  may  be  used  anywhere  a  timeint  variable  may  be  used,  but  there 
are  two  additional  operations,  START_TIMER  and  HALT_TIMER,  that  may  be  used. 
START  TIMER  increments  or  decrements  the  timer  until  a  limit  is  reached. 

When  a  timer  is  declared,  the  user  may  choose  between  timers  that 
increment  and  timers  that  decrement,  as  well  as  between  timers  that  halt  when 
they  reach  their  limit  and  timers  that  "wrap  around".  The  user  may  also 
specify  a  semaphore  that  will  be  incremented  when  the  timer  reaches  its  limit 

EC. TIMER. 2  Interface  Overview 

EC. TIMER. 2.1  Declaring  a  Timer 

Timers  are  a  numeric  type  class,  as  described  in  EC.DATA.l.  To  declare 
specific  timer  types,  use  the  ++DCL_TYPE++  program  specified  in  EC. DATA. 2.1, 
with: 

p2  =  TIMER; 

p3  a  timer-attribute,  defined  in  section  EC. TIMER. 3; 

and  the  other  parameters  as  described  there. 

Timer  entities  must  be  declared  before  they  can  be  used.  Use  the 
++DCL_£NTITY++  program  of  Section  EC. DATA. 2.2.1,  with: 

p3  ■  VAR;  and 

p4  the  initial  value  given  as  a  timeint  literal; 

and  the  other  parameters  as  described  there. 

To  declare  an  array  of  timers,  use  the  ++DCL_ARRAY++  program  of 
EC. DATA. 2. 2. 2,  with: 

p3  =  VAR; 

p4  as  described  there,  using  timeint  literals  as  initial 

values ; 

and  the  other  parameters  as  described  there. 
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EC.TIMER.2.2  Access  programs 

Program  name 

Parm  type 

Parm  Info 

Undesired  Events 

++TIME R_E VENTS ++ 

pi : timer ; I 
p2 : semaphore ; I 

timer  name 
limit  value  event 

None . 

+ START  TIMER* 
+HALT  TIMER* 

pi : timer ; I 

timer  name 

EC.TIMER.2.3  Timer  tests 
Program  name 
+TEST  TIMER* 


Parm  type 
pi :boolean;0 


Parm  Info 


Undesired  Events 


I+timer  test  result*!  None 


+HALT  TIMER* 


+ START  TIMER* 


++TIMER  EVENTS ++ 


+TEST  TIMER+ 


Program  Effects 

Causes  running  timer  pi  to  halt.  Halting  a  non~running 
timer  has  no  effect. 

Causes  the  value  of  pi  to  be  changed  in  value  in  real 
time.  The  value  will  be  increased  or  decreased  according 
to  the  declaration  of  the  specific  type  to  which  pi 
belongs.  According  to  the  declaration  of  the  specific 
timer  type  to  which  pi  belongs,  the  timer  will  either 
stop  when  it  reaches  its  minimum  (maximum)  value,  or 
"wraparound";  i.e.,  continue  from  its  maximum  (minimum) 
value.  Starting  a  running  timer  has  no  effect. 

Causes  an  event  to  be  signalled  (by  incrementing  p2) 
every  time  pi  reaches  its  minimum  range  value  (if  pi  is  a 
decrementing  timer)  or  its  maximum  range  value  (if  pi  is 
an  incrementing  timer). 

Reports  the  results  of  the  timer  hardware  tests.  If  the 
test  is  performed  periodically  or  independent  of  user 
request,  the  result  given  will  be  that  of  the  most  recent 
test.  If  the  test  is  performed  on  request,  the  command 
will  initiate  the  test  and  report  the  result  when  the 
test  is  complete.  It  may  interfere  with  normal  operation 
of  timers  and  input/output  commands  in  unpredictable  ways 
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timer 


The  name  of  a  time-keeping  mechanism  declared 
previously  by  a  user  program. 


timer-attribute  An  ordered  5-tuple  of  the  form 

(timeint,  timeint,  timeint,  HALT/WRAP,  UP/DOWN) 
The  first  three  elements  specify  the  lower  bound, 
upper  bound,  and  minimum  !! resolution ! 1 ,  respectively, 
of  entities  of  the  type.  The  fourth  element  is  either 
"HALT"  (meaning  that  the  timer  should  stop  when  it 
reaches  a  limit)  or  "WRAP"  (meaning  that  the  timer 
should  wrap  around  when  it  reaches  a  limit).  The 
fifth  element  is  either  "UP"  (meaning  that  the  timer 
increments  when  started)  or  "DOWN"  (meaning  that  the 
timer  decrements  when  started). 


EC. TIMER. 4  Dictionary 

1+timer  test  result+I  true  iff  the  timer  hardware  passes  built-in  test. 


EC. TIMER. 5  Undesired  Event  Dictionary:  None. 


EC. TIMER. 6  System  Generation  Parameters 

Parameter  Type  Definition 

#max  timer  error#  real  maximum  allowable  error  rate  of  all 

timers,  given  as  a  fraction  of  the  time 
interval  measured. 

#m ax  timer  range#  timeint  maximum  allowable  value  of  absv(upper 

bound  -  lower  bound)  for  a  timer  type. 

#max  timer  ranres  ratio  real  maximum  allowable  magnitude  of  the 

ratio  of  a  timer  type's  Jlrangell  to 
its  1 ^resolution! ! . 

#min  timer  resolution#  timeint  for  all  timers,  the  minimum  resolution. 
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EC. INDEX  INDICES  TO  THE  DOCUMENT 


This  section  provides  the  following  indices  to  the  facilities  described 
in  this  document: 

Access  programs 
Builtin  objects 

Events  signalled  by  incrementing  a  semaphore 
Types  provided 
Dictionary  terms 
Undesired  events 
System  generation  parameters 
Reserved  words 
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EC. 10 

++EXCLUSION++ 

EC. PAR. 2 

++EXIT++ 

EC. PGM. 1 

+G_SUCCESS+ 

EC.  10 

i 

+GEQ+ 

EC. DATA 

+GT+ 

EC. DATA 

+HALT  TIMER* 

EC. TIMER 

+LEQ+ 

EC. DATA 

+LT+ 

EC. DATA 

• 

+MINUS+ 

EC. DATA 

i 

+MUL+ 

EC. DATA 

+NAND+ 

EC. DATA 

+NEQ+  (bitstring) 

EC. DATA 

+NEQ+  (numeric) 

EC. DATA 

+NOT+ 

EC. DATA 

• 

+0R+ 

EC. DATA 

i 

++P  PROCESS** 

EC. PAR. 1 

+PASS+ 

EC. SMPH 

+R  BITS  2C0MP+ 

EC. DATA 

+R_B IT S  JPOSTI IVE+ 

EC. DATA 

, 

+  R  BITS  S IGNMAG+ 

EC. DATA 

• 

*R  TIME • HOUR* 

EC. DATA 

i 

+R  TIME  MIN* 

EC. DATA 

■ 

*R_TIME  MS* 

SC. DATA 

,  • 

i 

- 
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Access  Programs  (continued) 


Access  program 

+R_TIME_SEC+ 
++RANK_DATA++ 
++RANK_DATA_S  ET++ 
++RANK_PGM++ 
++REGION++ 

+REPLC+ 

+ S_FAI  L_S  TATE + 
+SET+ 

++SET++ 

+SHIFT+ 

+SIGN+ 

+ S  TART_T IMER+ 
+SUB+ 

+T_RE  AL_HO  UR + 

+T_REAL_MIN+ 

+T_REAL_MS+ 

+T_REAL_SEC+ 

+TEST_AC+ 

+TEST_CSA+ 

+TEST_CSB+ 

+TEST_DC+ 

+TEST_D  IOW1  + 

+TEST_DIOW2+ 

+TEST_DIOW3+ 

+TEST_INTERRUPTS+ 

+TE  S  T_MEMOR Y + 

+TEST_TIMER+ 

+TEST_XACC+ 

+TEST_YACC+ 

+TEST_ZACC+ 

++TIMER_EVENTS++ 

+UP+ 

+XOR+ 


Where  •  defined 

EC. DATA 
EC. DATA 
EC. DATA 
EC. PGM. 2 
EC. PAR. 2 
EC. DATA 
EC. STATE 

EC. DATA,  EC.SMPH, 

EC. DATA,  EC. PGM. 2 

EC. DATA 

EC. DATA 

EC. TIMER 

EC. DATA 

EC. DATA 

EC. DATA 

EC. DATA 

EC . DATA 

EC. 10 

EC.  10 

EC.  10 

EC.  10 

EC.  10 

EC.  1 0 

EC.  10 

EC. PAR. 1 

EC. MEM 

EC. TIMER 

EC. 10 

EC.  10 

EC.  10 

EC. TIMER 

EC.SMPH 

EC. DATA 


EC. PGM. 2 
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Builtin'Objects 

Name 

Type  of ' object 

Where  -  defined 

DIV_FAIL 

program 

EC. DATA. 2.6.2 

ECFAILED 

semaphore 

EC. STATE 

ECPOWUP 

semaphore 

EC. STATE 

ENBLSEM 

semaphore 

EC.  10 

ENTSWSEM 

semaphore 

EC.  10 

KBINTSEM 

semaphore 

EC.  10 

MARKSEM 

semaphore 

EC.  10 

NEXT  PERIOD 

semaphore 

EC. PAR. 1 

REG 

data  object 

EC. DATA. 1.4 

All  i/o  data  items 

bitstring 

EC.  10 

All  undesired  events 

program 

EC. PGM. 2 

All  EC  access  programs 

program 

EC. PGM. 2 

Boolean  UE  variables 

boolean 

EC. PGM. 2 

Event 


Events  Signalled -by  - Incrementing -a  -  Semaphore 


Semaphore 


Where 'defined 


@T( I +/ENTERSW/  occurred+1 )  ENTSWSEM 

@T( ! +failed  state*!)  ECFAILED 

@T(  ! +/KBDENBL/  occurred*!)  ENBLSEM 

@T(  !  +/KBDINT/  ready+!  )  KBINTSEM 

@T( I +/MARKSW/  occurred*!)  MARKSEM 

0T( ! +power  up+!)  ECPOWUP 


EC. 10  (Appendix  5) 
EC. STATE 

EC. 10  (Appendix  5) 
EC. 10  (Appendix  5) 
EC. 10  (Appendix  5) 
EC. STATE 


In  addition,  users  may  request  timer-related 

events  by  supplying  their  own  semaphores.  See  EC. TIMER 


I 
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Types  Provided 


Type • name 

Where  -  defined 

array-init 

EC. DATA 

attribute 

EC. DATA 

binding 

EC. DATA 

bitstring 

EC. DATA 

boolean 

EC. DATA 

convar 

EC. DATA 

data  set  rein 

EC. DATA 

dataitem 

EC.  10 

El 

EC. PGM. 1 

entrance 

EC. PGM. 3 

exclusion-relation 

EC. PAR. 2 

indexset 

EC. DATA 

integer 

EC. DATA 

invocation 

EC. PAR. 1 

name 

EC. DATA 

parm 

EC. PGM. 3 

parm-lis  t 

EC. PGM. 3 

pgm-attr ibute 

EC. PGM. 2 

pointer 

EC. DATA 

program 

EC. PGM. 2 

rank-data-relation 

EC. DATA 

rank-pgm-r elation 

EC. PGM. 2 

real 

EC. DATA 

semaphore 

EC.SMPH 

semaphore-attribute 

EC.SMPH 

spectype 

EC. DATA 

statement- list 

EC. PAR. 2 

timeint 

EC. DATA 

timer 

EC. TIMER 

timer-attribute 

EC. TIMER 

typeclass 

EC. DATA 

vers  ion 

EC. DATA 

In  addition,  Appendix  5  lists 
bitstring  spectypes. 

a  set  of  builtin 
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- 

I 

s 

Bietionary 

Terms 

*» 

X 

Term 

T/#here  -  defined 

1 

-1 

*  ■ 

Ilactual  parameter!! 

EC. PGM. 3 

! ! command ! ! 

EC. PGM. 1 

! Iconstructed  program!! 

EC. PGM. 1 

! +deadline+! 

EC. PAR. 1 

j 

! +des  tination*! 

EC. DATA 

A 

■ 

! ! destination! ! 

EC. DATA 

y  / 

!+/ENTERSW/  occurred*! 

EC.  10 

- 

wV 

!+failed  state+! 

EC. STATE 

N.*  * 

l*fall  back  value*! 

EC. DATA 

•• 

c. 

.'.’hardest  attributes!! 

EC. DATA 

!+interrupt  test  result+! 

EC. PAR. 1 

» 

! ! invocation! ! 

EC. PGM. 1 

! +io  test  result*! 

EC.  TO 

■ 

!+i/o  success*! 

EC.  10 

I+/KBDENBL/  occurred+! 

EC.  10 

1+/KBDINT/  ready*! 

EC.  10 

t 

• 

! !  list! ! 

EC. DATA 

f 

t 

I +/MARKSW/  occurred* ! 

EC.  10 

>.- 

!*max  CPU  time  req*! 

EC. PAR. 1 

*, 

I +raax  div  result*! 

EC. DATA 

! +meraory  test  result*! 

EC. MEM 

I +on/off+! 

EC. PAR. 1 

! +period+! 

EC. PAR. 1 

1 

>  • 

!+power  up*! 

EC. STATE 

I +radix  pt  ident*! 

EC. DATA 

! ! range! ! 

EC. DATA 

. 

*" .  - 

I !relation! ! 

EC. DATA 

.•! 

! !resolution! ! 

EC. DATA 

r»Bi 

I +source+! 

EC. DATA 

! ! source ! I 

EC. DATA 

!+starting  event*! 

EC. PAR. 1 

!+timer  test  result*! 

EC. TIMER 

!+user  threshold*! 

EC. DATA 

ji 

_ 

1 

• 

» 

— 

» 

• 

■ 

r 
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EC.  INDEX 


Hndes ired -  Events 


UE  name 


Where  - de  fined  Also -appears  -  in 


%already  disabled% 

%already  enabled% 

^assertion  violation% 

%%attribute  not  allowed%% 
%%attribute  not  given%% 
%%constant  destination%% 

%%dest  unknown%% 

%divide  by  zero% 

%%duplicate  name%% 

%%entrance  incorrectly  oraitted£% 
%il legal  array  index% 

%%illegal  exit-list%% 

%%illegal  index  set%% 

%%illegal  ptr  target%% 

%il legal  round/ trunc% 

%%illegal  synch%% 

%%inappropriate  attributes%% 
%%inconsistent  data  ranking%% 
%inconsistent  lengths% 
%%inconsistent  pgm  ranking%% 
%%inconsistent  pgras%% 

%% inconsistent  register  access%% 
^inconsistent  time  parms% 

%%index  not  allowed%% 

%left  truncation% 

%%length  too  great%% 

%%literal  or  ascon  too  big%% 
%%loadcon  too  big%% 

%max  CPU  time  exceeded% 

%mdr  outside  range% 

%missed  deadline!? 

%%multiple  qualifiers^ 

%%name  in  use%% 

%%no  such  entrance%% 

%nonexistent  position% 


EC.  10 
EC.  10 
EC. DATA 
EC. DATA 
EC. DATA 
EC. PGM. 3 
EC. PGM. 1 
EC. DATA 
EC. PGM. 1 
EC. PGM. 3 
EC. DATA 
EC. PGM. 1 
EC. DATA 
EC. DATA 
EC. DATA 
EC. PAR. 1 
EC. DATA 
EC. DATA 
EC. DATA 
EC. PGM. 2 
EC. PGM. 2 
EC. DATA 
EC. PAR. 1 
EC. DATA 
EC. DATA 
EC. DATA 
EC. DATA 
EC. DATA 
EC. PAR. 1 
EC. DATA 
EC. PAR. 1 
EC. DATA 
EC. DATA 
EC. PGM. 1 
EC. DATA 


EC. PAR. 2, 


EC. PGM. 1 
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Undesired  Events  (continued) 


UE  name 


Where -defined  Also -appears  -  in 


??not  an  entranced 
??not  an  exit?? 

? nowhere  to  go % 

%%parm  wrong  type?? 

??port  defined  twice%% 

??port  not  defined?? 

%range  exceeded% 

%%range  too  great%% 

%%ranres  too  great%% 

??read/wr ite-only  violation!?? 
?read-write  violation? 

?recursive  call? 

?%REG  not  allowed?? 

??res  too  fine?? 

??subrange  not  allowed?? 

??too  few  par ms?? 

%?too  many  parms?? 

??undeclared  operand?? 

??undeclared  program?? 

??undeclared  region?? 

??undeclared  spectype?? 

??un implemented  attribute 
via  variables?? 

??un implemented  binding?? 

??un implemented  disabling?? 
??unimplemented  EXACT  REP  resolution?? 
??un implemented  multi-exit  EC 
access  program?? 

??un implemented  pgm  ptr?? 

??un implemented  variable  period?? 

??un implemented  variable 
shift  length?? 

??unimplemented  variable  substring?? 
??unimpleraented  varying  EXACT_REP?? 
?unititialized  pgm? 

??unknown  initial  value?? 

??unknown  operand  in  attributes?? 
??variable  parm?? 

??variable  timing  parms?? 

??varying  constant?? 

??wrong  init  value  size?? 

??wrong  init  value  type?? 


EC. PGM. 3 
EC. PGM. 1 
EC. PGM. 1 
EC. PGM. 3 
EC. PGM. 1 
EC. PGM. 1 
EC. DATA 
EC. DATA 
EC. DATA 
EC.  10 
EC.  10 
EC. PGM. 3 
EC. DATA 
EC. DATA 
EC. DATA 
EC. PGM. 3 
EC. PGM. 3 
EC.:  VTA 
EC. PGM. 3 
EC. PAR. 2 
EC. DATA 
Appendix  4 

Appendix  4 
Appendix  4 
Appendix  4 
Appendix  4 

Appendix  4 
Appendix  4 
Appendix  4 

Appendix  4 
Appendix  4 
EC. PGM. 2 
EC. DATA 
EC. DATA 
EC. DATA 
EC. PAR. 1 
EC. DATA 
EC. DATA 
EC. DATA 


EC.SMPH 


EC. PAR. 1 
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EC. INDEX 


System  Generation • Parameters 


Parameter  name 

Bata ' type 

Where 'defined 

#close  down  time# 

timeint 

EC. STATE 

#max  bits  length# 

integer 

EC. DATA 

#max  i/o  time  (data  item  name)# 

timeint 

EC.  10 

#max  real  as con# 

real 

EC. DATA 

#max  real  loadcon# 

real 

EC. DATA 

#raax  real  range# 

real 

EC. DATA 

#max  real  ranres  ratio# 

real 

EC. DATA 

#max  semaphore  ascon# 

semaphore 

EC.SMPH 

#max  semaphore  loadcon# 

semaphore 

EC.SMPH 

#raax  semaphore  range# 

semaphore 

EC.SMPH 

#max  time in t  ascon# 

timeint 

EC. DATA 

#raax  timeint  loadcon# 

timeint 

EC. DATA 

#max  timeint  range# 

time int 

EC. DATA 

#raax  timeint  ranres  ratio# 

real 

EC. DATA 

#max  timer  error# 

real 

EC. TIMER 

#max  timer  range# 

timeint 

EC. TIMER 

■■‘max  timer  ranres  ratio# 

real 

EC. TIMER 

#min  real  resolution# 

real 

EC. DATA 

#min  timeint  resolution# 

timeint 

EC. DATA 

#rain  timer  resolution# 

timeint 

EC. TIMER 

#nbr  fltrec  elements# 

integer 

EC.  10 
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Reserved  Words 


Word 

Type 'of -word 

Where  - de fined 

ASCON 

Enumerated  type  value 

EC. DATA 

BITS 

Typeclass 

EC. DATA 

BOOLEAN 

Builtin  spectype 

EC. DATA 

DEREF 

Keyword  in  pointer  use 

EC. DATA 

DOWN 

Attribute  keyword 

EC. TIMER 

EXACT  REP 

Attribute  keyword 

EC. DATA 

EXIT1 

Exit  of  certain  EC  programs 

EC. PGM. 2 

£false$ 

Boolean  value 

EC. DATA 

FIX 

Enumerated  type  value 

EC. DATA 

HALT 

Attribute  keyword 

EC. TIMER 

INTEGER 

Typeclass 

EC. DATA 

LOADCON 

Enumerated  type  value 

I ^destination! !  identifier 

EC. DATA 

NOSTORE 

EC. DATA 

PGM 

Typeclass 

EC. PGM. 2 

PTR 

Typeclass 

EC. DATA 

REAL 

Typeclass 

EC. DATA 

REF 

Keyword  in  pointer  literal 

EC. DATA 

ROUND 

Operand  keyword 

EC. DATA 

-SAVE 

Keyword 

EC. DATA. 1.4 

SEMAPHORE 

Typeclass 

EC.SMPH 

TIMEINT 

Typeclass 

EC. DATA 

TIMER 

Typeclass 

EC. TIMER 

$true$ 

Boolean  value 

EC. DATA 

TRUNC 

Operand  keyword 

EC. DATA 

UP 

Attribute  keyword 

EC. TIMER 

VAR 

Enumerated  type  value 

EC. DATA 

VARY 

Enumerated  type  value 

EC. DATA 

WRAP 

Attribute  keyword 

EC. TIMER 
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Design  Issues 


EC. DATA 

1.  We  decided  to  give  the  programmer  some  control  over  the  register,  so 
chat  he  could  take  care  of  reducing  register  loads  and  stores  by 
being  careful  with  the  order  of  operations.  The  alternatives  we 
considered  were  notations  much  closer  to  high-level  programming 
languages.  These  notations  make  complex  expressions  easier  to  read, 
but  require  a  more  sophisticated  translator  if  we  are  to  make 
efficient  use  of  registers. 

2.  There  is  a  danger  with  fixed  point  division  that  the  results  will  be 
meaningless;  this  problem  occurs  when  the  numerator  has  more 
significance  than  the  denominator.  An  assembly  language  programmer 
has  some  information  that  he  uses  to  avoid  this  danger.  The  only  way 
we  can  get  this  information  is  to  ask  the  programmer  to  provide  it, 
since  it  is  dependent  on  the  context  and  meaning  of  the  division. 

3.  Two  ways  were  proposed  for  user  programs  to  indicate  the  radix  of  the 
number  for  a  bitstring-real  conversion: 

a.  by  giving  an  integer  literal  "i"  such  that  the  rightmost  bit  of 
the  bitstring  represents  2  raised  to  the  ith  power; 

b.  by  giving  an  integer  literal  "i"  such  that  i  is  the  number  of  the 
bit  immediately  to  Che  right  of  the  radix  pt. 

Alternative  2  most  closely  resembles  the  scaling  notation  used  in  the 
current  program,  but  we  chose  alternative  1  because  most  designers 
felt  that  it  was  easier  for  newcomers  to  understand  and  remember. 

4.  There  are  two  main  reasons  for  including  variables  whose  attributes 
may  vary: 

a)  they  can  be  reused  at  different  points  in  a  computation,  thereby 
reducing  the  amount  of  space  that  must  be  reserved; 

b)  they  allow  the  same  code  to  be  used  to  manipulate  values  in 
widely  differing  ranges. 

5.  We  require  the  programmer  to  specify  a  type  for  results  stored  into 
and  retrieved  from  variables.  We  considered  permitting,  but  not 
requiring,  specification  of  the  type  of  intermediate  results  and 
letting  the  Extended  Computer  determine  the  specific  type  when  the 
programmer  omitted  the  specification.  We  ruled  out  this  alternative 
because  it  requires  a  run-time  support  package  to  keep  track  of  the 
specific  types  of  varying-type  variables. 
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6.  We  considered  several  alternatives  for  providing  registers: 

a)  Having  a  common  register  for  all  type  classes.  This  register  can 
be  very  simply  mapped  to  the  accumulator. 

b)  Having  a  separate  register  for  each  type  class,  implementing  them 
with  the  single  accumulator,  and  leaving  the  problem  of  interference 
between  them  up  to  the  programmer.  This  was  originally  accepted 
because  it  is  the  simplest  alternative  that  provides  type  checking  for 
results  in  the  register.  However  it  gives  away  the  underlying 
limitation,  and  imposes  restrictions  on  the  programmer  that  would  not 
be  needed  if  the  underlying  hardware  had  more  registers  or  if  there 
was  multi-processor  hardware. 

c)  Having  a  separate  register  for  each  type  class,  implementing  them 
with  the  single  accumulator,  and  completely  automating  the  problem  of 
interference  between  the  registers,  freeing  the  programmer  from  any 
concern  about  it.  This  could  be  done  by  saving  and  restoring  the 
accumulator  contents  whenever  a  different  register  is  used.  While  it 
would  be  the  most  convenient  alternative,  the  overhead  would  be 
prohibit ive . 

d)  Having  a  separate  register  for  each  type  class,  implementing  them 
with  the  single  accumulator,  and  partially  automating  the  problem  of 
interference  between  the  registers.  The  programmer  would  have  to 
indicate  when  he  wants  to  reuse  results  in  a  particular  register  and 
when  he  does  not  care. 

We  chose  alternative  (a)  because  it  is  the  simplest  and  treats  a 
register  as  a  variable  with  varying  attributes. 

7.  We  felt  it  important  that  the  EC  implementation  avoid  saving  contents 

of  a  register  if  they  would  never  be  needed  and  therefore  put  that 
burden  on  the  programmer  rather  than  try  to  do  register  usage 

analysis.  We  considered  several  ways  to  allow  the  programmer  to 

specify  whether  or  not  the  value  in  the  register  would  be  needed 
again.  Among  them: 

a.  Associate  the  information  with  the  name  of  the  register. 

b.  Associate  the  information  with  the  name  of  the  operation. 

We  chose  (b)  because  we  did  not  want  to  have  two  names  for  the  same 
object.  Further,  it  allows  us  to  localize  the  information  in  a  place 
related  to  the  operations  (of  which  it  is  a  property)  rather  than  the 
registers . 

8.  An  earlier  version  of  this  interface  included  operations  such  as 
squareroot,  exponentiation,  log,  and  root-sum-squared.  We  decided  to 
move  these  operations  to  another  module  because  they  can  be 
implemented  in  a  machine-independent  fashion.  These  concerns  do  not 
belong  in  the  Extended  Computer. 
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9.  An  earlier  version  of  this  module  had  two  bitstring  sizes, 
corresponding  to  halfwords  and  fullwords  on  the  target  computer.  We 
then  decided  to  have  only  one  size  because  it  results  in  a  simpler 
data  type.  We  finally  decided  to  have  bitstrings  of  any  size  because 
we  noted  that  insisting  on  a  fixed  but  unknown  size  made  it  difficult 
to  write  efficient  but  machine  indeoendent  code.  The  present  choice 
makes  the  interface  unbiased  with  respect  to  word  length  and  puts  the 
burden  for  effective  use  of  the  actual  hardware  on  the  implementor  of 
the  EC. 

10.  We  considered  specifying  bitstring  sub  ranges  in  terms  of 
(starting  point,  length)  instead  of  (starting  point,  ending  point). 

One  parameter  fewer  would  be  needed  on  bitstring  compares  and 
transfers,  and  we  could  avoid  the  unmatching  lengths  undesired  event. 
However,  we  found  that  people  working  with  bitstrings  find  it  easier 
to  work  by  identifying  the  boundary  bits. 

11.  We  considered  having  the  EC  monitor  arithmetic  operations  for 
excessive  loss  of  significance  but  decided  that  this  was  a  programmer 
responsibility  and  could  be  done  in  a  machine  independent  way.  This 
eliminated  the  undesired  event  %too  much  lost  signif icance%. 

12.  We  considered  relegating  time  to  the  application  data  type  module  and 
implementing  it  in  terms  of  reals.  We  chose  to  include  it  in  the  EC 
because  the  concept  of  time  is  basic  to  the  specification  and 
implementation  of  real-time  processes  in  the  EC  and  because  the 
representation  should  be  that  used  in  the  hardware  timers. 

13.  We  considered  allowing  array  declarations  to  be  shared  by  several 
variables.  We  found  this  not  particularly  useful  unless  one  has 
operations  that  take  whole  arrays  as  operands. 

14-.  We  decided  not  to  allow  array  elements  to  be  structures.  We  lose  the 
ability  to  have  arrays  of  arrays,  but  if  this  were  necessary,  it  could 
be  implemented  in  a  machine  independent  way  and  could  be  provided  by 
some  other  module. 

15.  We  considered  allowing  index  sets  to  be  more  general,  but  this  seemed 
unnecessary  even  for  future  extensions.  Such  extensions  could  be  done 
using  the  present  arrays  and  the  extension  would  be  machine 
independent.  We  also  considered  restricting  the  lower  array  bound  to 
be  either  0  or  1.  This  seemed  unnecessarily  restrictive,  especially 
as  it  may  be  desirable  to  select  array  indices  at  sysgen  time. 

lb.  We  considered  fixing  the  value  of  the  array  index  set  at  declaration 
time,  system  generation  time,  or  run  time.  Declaration  time  is  too 
restrictive;  it  is  sometimes  useful  for  the  array  index  set  to  be  a 
system  generation  parameter.  Run  time  fixing  reauires  dynamic  storage 
allocation,  which  is  not  needed  or  practical  for  avionics  aoplications 
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17.  We  rejected  the  option  of  operations  that  apply  to  arrays  as  units, 
e.g.  multiplying  arrays  by  scalars  or  arrays  by  arrays.  Such 
operations  depend  on  mathematical  algorithms,  rather  than  on 
character istics  of  the  computer  and  can  be  implemented  in  a 
machine-independent  way.  The  present  design  is  the  simplest  way  to 
hide  the  hardware  addressing  mechanism.  Extentions  can  be  provided  by 
user  programs. 

18.  We  considered  not  allowing  arrays  of  variables  whose  attributes  vary 
at  run-time  as  it  might  simplify  the  implementation  if  all  elements 
had  the  same  attributes  at  all  times.  Although  the  implementation  of 
arrays  with  varying  attributes  will  probably  be  less  efficient  than 
arrays  of  fixed  attribute  elements,  this  feature  is  occasionally 
needed. 

19.  More  than  one  reviewer  asked  if  the  Extended  Computer  shouldn't 
provide  stacks  as  a  builtin  data  structure.  If  we  need  stacks,  they 
can  be  provided  using  the  current  EC  facilities.  The  interface  to 
those  facilities  (probably  in  the  ADT  module)  would  be  carefully 
modelled  after  the  EC.  Should  we  transfer  to  stack  machine,  we  could 
move  the  interface  into  the  EC,  and  user  programs  would  not  have  to 
change.  This  rationale  also  applies  to  floating  point  arithmetic, 
multi-dimensional  arrays,  array  operators,  etc. 

20.  Entity  names  are  global  in  the  EC.  This  is  because  that  is  what 
avionics  computers  provide;  one  can  limit  the  scope  of  a  name  (if 
desired)  in  a  machine-independent  way  (e.g.,  using  naming  conventions, 
or  a  pre-processor). 

21.  We  recognize  the  need  to  represent  data  most  efficiently  for  the 
operations  in  which  it  will  be  used.  Since  only  users  can  determine 
hew  a  datura  will  be  used,  the  best  the  EC  can  do  is  provide  a  menu  of 
representations  and  tell  the  users  what  each  one  is  best  and  worst  at 
doing.  Hence,  the  "version"  attribute  in  specific  types. 

22.  We  considered  allowing  non-homogenous  arrays;  that  is,  arrays  with 
different  specific  types.  However,  that  would  mean  that  if  an  operand 
was  a  member  of  such  an  array,  we  couldn't  discover  its  type  until 
run-time.  Because  of  this  great  run-time  penalty,  we  deleted  the 
capability. 
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23.  The  +SHIFT+  program  used  Co  Cake  a  lisC  of  biCsCrings  as  iCs  inpuc 
parameCer;  ic  shifCed  Che  concaCenaC ion  of  Che  lisC.  The  idea  was  Co 
allow  the  same  kind  of  shifting  that  occurs  in  the  TC-2  between 
adjacent  registers.  However,  ic  became  clear  that  the  implementation 
of  such  a  feature  would  simply  +CAT+  the  strings  together  first 
anvwav,  and  shifting  Che  result,  and  we  would  gain  no  efficiency.  So 
for  consistency,  +SHIFT+  now  takes  a  single  source  parameter. 

24.  We  have  made  the  decision  Co  design  the  EC  to  be  implemented  on  a 
machine  chat  supports  fixed-point  arithmetic  and  not  floating-point 
arichmetic.  The  resolution  required  in  a  numeric  variable  is 
expressed  in  our  machine  as  a  constant,  independent  of  the  magnitude 
of  the  value  of  the  variable.  In  fixed-point  represenatations ,  there 
is  a  uniform  distance  between  values  that  can  be  represented  exactly. 
In  floating-point,  the  distance  is  small  for  small  values,  large  for 
large  values. 

Were  we  to  go  to  a  floating-point  machine,  we  would  need  to  enhance 
the  interface,  because  fixed-distance  representations  on  a  floating¬ 
point  machine  would  be  very  inefficient.  We  would  let  the  user 
specify  a  worst-case  distance  between  representatives  as  a  fraction  of 
the  value  of  the  variable.  The  implementation  would  choose  a 
representation  so  that  the  mantissa  of  the  number  had  a  resolution  (in 
the  current  sense)  less  than  the  fraction. 

The  present  interface  mav  be  considered  a  subset  of  a  more  complete 
interface  in  which  we  let  the  user  specify  resolution  either  in 
absolute  form  (in  which  case  a  fixed-point  representation  would 
probably  be  chosen)  or  in  relative  form  (in  which  case  we  would 
represent  the  number  using  the  floating-point  hardware,  or  by 
simulating  floating-point).  The  present  interface  reflects  our 
decision  to  make  EC  apply  to  typical  avionics  machines,  which  are 
f ixed-point . 

25.  The  pointer  typeclass  is  a  recent  addition,  included  when  we  realized 
that  we  had  denied  users  the  capability  found  in  all  von  Neumann 
machines  of  indirect  referencing,  or  postponing  operand  specification 
until  run-time.  Since  the  goal  of  EC  was  to  abstract  from  the 
idiosyncrasies  of  particular  avionics  computers,  yet  provide  the 
capabilities  that  they  provide,  this  was  clearly  an  appropriate 
addition  to  the  EC  architecture. 
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26.  When  declaring  a  specific  type,  it  used  to  be  an  error  to  specify  a 

version  that  did  not  exist  for  that  particular  type.  We  now  say  ^ 

merely  that  the  EC  will  pick  one  of  its  own  choosing  in  that  case. 

That  is  so  that  should  an  Application  Data  Types  type  ever  migrate 
into  the  EC  because  of  a  change  that  enhances  the  type  repertoire  of 
the  hardware,  we  would  like  for  user  programs  to  remain  correct. 

However,  the  versions  that  we  would  provide  in  the  EC  for  that  type 
might  be  entirely  different  than  what  were  provided  for  it  in  the  ADT.  9 


CRF  262 


8944a 


79 


Appendix  1 
Release  7 


Design  Issues 


EC.  10 

1.  We  considered  five  alternatives  for  handling  retries  of  unsuccesful 
I/O  operations : 

1)  having  two  different  commands  for  these  two  cases:  one  that 
retries,  either  once  or  until  it  succeeds,  and  one  that  instead  of 
retrying  returns  a  failure  indicator; 

2)  having  a  parameter  on  the  command  specifying  how  often  to  retry, 
and  having  the  command  return  a  failure  indicator; 

3)  having  a  failure  indicator,  and  having  the  user  program  try  again 
if  it  needs  to  retry  transmission; 

4)  having  a  special  "retry"  command,  with  a  label  operand,  which  the 
user  can  call  to  have  the  I/O  command  with  the  specified  label 
retried. 

5)  omitting  the  failure  indicator  for  the  data  items  where  it  is  not 
currently  used. 

The  first  and  fourth  alternatives  yield  a  more  complicated  interface 
than  the  third  and  provide  no  extra  capability.  The  second  results  in 
extra  (non-machine  dependent)  programs  in  the  EC.  The  fifth 
alternative  would  build  knowledge  of  the  application  into  the  EC.  The 
third  alternative  relegates  decisions  about  retrying  to  the  user 
programs,  and  we  chose  this  one. 

3.  We  have  considered  four  alternatives  for  handling  the  discrete  inputs 
and  outputs. 

Alternative  1:  Treating  input  and  output  differently,  allowing  user 
programs  to  use  a  READ  command  to  read  in  entire  discrete  input  words, 
but  providing  a  special  WRITEBOOL  command  so  that  user  programs  could 
write  individual  bits  appearing  in  the  discrete  output  words. 

Alternative  2:  Adding  a  READBOOL  command  that  would  read  in  a 
discrete  input  word,  pick  out  the  bit  for  a  particular  discrete  input 
data  item,  and  return  it  as  a  boolean  value.  Alternative  2  was 
rejected  because  not  all  the  data  items  in  discrete  input  words  have 
boolean  values.  For  example,  /IMSMODE/  has  five  values,  one  for  each 
switch  position. 

Alternative  3:  Provide  the  user  programs  with  a  way  to  specify  a 
range  of  bits  within  both  a  discrete  output  word  that  they  want  to 
write  out  and  within  an  input  word,  so  that  they  can  request 
individual  discrete  inputs  in  a  symmetrical  fashion.  Alternative  3 
leaves  some  of  the  responsibility  for  non-interference  between 
discrete  outputs  to  the  device  interface  modules,  since  they  must 
specify  the  correct  ranges. 
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Current :  All  of  the  above  alternatives  were  based  on  the  decision 

that  the  EC  would  sometimes  identify  outputs  and  inputs  by  class  name 
rather  than  the  individual  data  item  name.  This  was  done  both  for 
efficiency  reasons  and  because  it  was  believed  that  knowledge  of  the 
location  of  a  data  item  within  a  discrete  input  or  output  word  was 
device  dependent  rather  than  computer  dependent.  A  much  more 
consistent  interface  is  achieved  by  always  using  the  data  item  name. 
The  EC  implementer  is  now  responsible  for  knowing  the  identity  of  a 
TC-2  I/O  item,  but  not  responsible  for  knowing  its  meaning.  The 
efficiency  problems  are  resolved  by  allowing  a  single  command  to  take 
a  list  of  parameters  so  that  the  EC  implementation  may  perform 
operations  to  a  single  I/O  word  simultaneously  rather  than 
sequentially.  This  also  eliminates  special  treatment  of  double  data 
items . 

4.  We  originally  designed  the  reading  of  intermittent  data  with  an  access 
function  that  indicated  whether  or  not  the  data  were  available  and  an 
undesired  event  if  a  user  program  tried  an  intermittent  read  operation 
when  the  data  were  not  available.  This  seemed  dangerous,  since  a 
slight  timing  difference  could  cause  an  undesired  event,  and  the  user 
programs  could  not  avoid  the  UE.  Instead,  we  have  chosen  to  allow  the 
read  command  at  any  time.  If  the  data  are  not  available,  the  success 
indicator  returns  false.  This  is  consistent  with  our  general  policy 
that  it  should  be  possible  to  avoid  UEs  by  correct  programming. 

Because  the  intermittent  data  is  read  just  like  any  other,  we  decided 
not  to  have  a  separate  command  name  for  it. 

5.  We  considered  having  serial  inputs  identified  by  class  names  rather 
than  by  individual  data  item  name.  Interpretation  of  the 
identification  bits  was  considered  the  responsibility  of  the 
associated  device  interface  module.  We  decided  that  identification  of 
the  data  item  is  an  EC  responsibility,  but  interpretation  of  the  item 
remains  the  responsibility  of  the  DIM. 

6.  Note  that  sometimes  an  output  should  go  to  more  than  one  data  item. 

We  originally  handled  this  by  letting  users  repeat  sets  of  parameters 
to  i/o  commands,  and  saying  that  the  order  was  unspecified.  Since  we 
no  longer  have  i/o  commands  per  se,  but  rather  use  assignment  (and 
other  bitstring)  operations,  we  have  expanded  our  general  assignment 
statement  so  that  many  sources  and  many  destinations  can  be  given  at 
once;  the  assignment  happens  in  an  unspecified  order. 
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7.  We  promise  that  an  output  transmission  will  occur  when  an  enabled 
output  data  item  is  used  as  a  destination.  We  do  not  say  when  an 
input  transmission  will  occur.  This  is  because  we  can  get  away  with 
it  in  the  latter  case,  but  not  in  the  former  (because  an  output 
transmission  has  visible  effects).  We  hide  when  input  takes  place 
because  someday  there  may  be  direct-memory-access  input,  and  the 
computer  really  won't  be  able  to  control  when  an  input  item  changes 
value . 

8.  We  did  not  include  the  names  of  the  data  items  in  the  main  document, 
because  we  wanted  to  emphasize  the  fact  that  the  architecture  of  the 
Extended  Computer's  i/o  operations  doesn't  depend  on  those  particular 
names.  If  the  design  of  the  Extended  Computer  were  used  with  the  TC-2 
for  some  other  application,  the  names  of  the  data  items  would  not  be 
part  of  the  technology  transferred. 

9.  We  chose  special  names  for  the  data  items'  bitstring  spectypes  because 
we  felt  that  the  representation  for  each  was  likely  to  change  in  the 
event  of  a  device  replacement,  and  probably  wouldn't  be  the  same  as 
that  of  a  non-data-item  bitstring  anyway.  For  instance,  we  might 
choose  to  represent  "normal"  bitstrings  as  contiguous  and 
left-justif ied  within  a  word,  but  we  clearly  don't  have  this  option 
with  most  of  the  data  items  (see  // FPANGL//,  for  instance). 

10.  The  signal  converter  is  tested  by  sending  particular  values  to  it  and 
then  reading  back  the  results  of  the  internal  signal  converter 
manipulation  on  the  values.  The  proper  relationship  between  the 
values  sent  out  and  the  value  read  in  can  be  characterized  by  a  set  of 
equations.  The  design  issue  is  how  much  of  the  knowledge  should  be 
hidden  within  this  module:  both  the  equations  and  the  choice  of  test 
values,  just  the  equations,  or  neither.  The  equations  are  based  on 
the  behavior  of  the  channel,  and  therefore  belong  within  this  module. 
The  choice  of  values  could  be  considered  part  of  the  software 
requirements;  they  affect  the  displays  seen  by  the  pilot,  and  are 
documented  in  section  4  of  the  requirements.  However,  the  choice  of 
these  particular  values  is  partly  influenced  by  hardware 
characteristics.  Further,  if  they  are  not  hidden,  the  interface  to 
this  module  becomes  much  more  complex.  We  have  chosen  to  hide  all  of 
the  information  even  though  it  means  hiding  some  details  about  the 
required  functions  in  this  interface.  We  assume  that  the  test  values 
are  likely  to  change  with  the  hardware  and  not  for  any  other  reason. 

11.  We  decided  to  hold  user  programs  responsible  for  avoiding  interference 
between  the  diagnostics  and  the  regular  commands  rather  than  build 
monitors  into  the  I/O  commands  and  diagnostics.  The  diagnostics  are 
not  expected  to  be  run  when  the  software  is  doing  anything  else. 
Monitors  impose  a  run-time  cost  in  the  regular  commands. 
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EC. MEM 

1.  We  considered  dividing  memory  into  banks  that  would  be  tested 
separately,  allowing  partial  rather  than  complete  shutdown.  We 
decided  not  to  do  so  ' t  this  time  because  the  system  lacks  the  ability 
to  exploit  it  and  we  could  do  so  easily  in  the  future. 

2.  A  previous  design  implied  that  invoking  the  access  program  associated 
with  a  test  actually  started  the  test.  Because  future  computers  may 
have  tests  ongoing,  or  running  in  the  background,  we  changed  our 
design  to  indicate  that  invoking  a  program  merely  returns  the  most 
recent  result  of  that  test.  If  a  future  computer  is  required  to  start 
a  test  at  a  certain  time,  we  can  add  start-test  commands  later. 
Returning  the  value  may  take  a  substantial  amount  of  time  in  some 
cases.  The  major  change  this  caused  was  in  the  case  of  the  memory 
test.  Before,  there  was  a  command  to  start  the  test,  an  event 
signalled  when  it  was  done,  and  a  program  to  retrieve  the  result.  The 
motive  was  that  the  invoking  program  would  want  to  do  something  else 
while  waiting  for  the  test  to  be  completed.  However,  some  program 
would  have  to  wait  idly  for  the  event  to  occur  anyway,  and  so  we  lose 
nothing  by  letting  the  memory  test  program  just  take  a  long  time  to 
return.  We  gain  a  uniform  interface,  with  no  special  cases. 

Other  design  issues  dealing  with  the  hidden  portion  of  the  interface  are 

contained  in  [VM] . 
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1.  In  earlier  designs  of  this  interface,  timing  constraints  were 
associated  with  specially  designated  blocks,  implying  that  these 
blocks  were  the  scheduling  units.  The  process  mechanism  was 
unnecessarily  complicated,  put  too  many  restrictions  on  the  internal 
structure  of  processes,  and  gave  away  more  information  than  the  one 
here. 

2.  We  considered  having  START  and  STOP  commands  so  that  one  process  can 
explicitly  affect  the  ready/waiting  state  of  another  process.  The 
problem  with  a  STOP  command  is  that  a  process  cannot  be  safely  stopped 
at  any  arbitrary  point.  We  fixed  this  by  adding  "homing  points",  but 
specifying  homing  points  also  cluttered  up  the  algorithm 
descriptions.  So  we  dropped  the  idea,  relying  on  more  conventional 
synchronization  mechanisms  instead. 

3.  Earlier  versions  made  an  outer  "do  forever"  loop  implicit.  Thus  the 
process  would  execute  a  "INIT"  block  once  whenever  the  process  was 
started  and  then  repeatedly  execute  a  "FREO"  block  until  the  process 
was  stopped.  We  have  decided  not  to  include  an  implicit  loop  because 
we  do  not  want  to  Limit  the  internal  structure  of  the  processes. 

Also,  the  process  would  be  easier  to  read  if  all  the  control  was  shown 
explicitly.  Process  bodies  can  now  be  specified  just  as  subprogram 
bodies  are,  making  the  overall  specifications  of  the  Extended  Computer 
simpler. 

4.  At  one  point  we  had  intermittent  processes  wait  for  a  start  event  and 
then  run  until  a  stop  condition  existed.  We  found  it  simpler  to 
define  a  single  boolean  and  have  the  process  pass  its  start  point  only 
when  the  boolean  was  true.  This  eliminated  the  need  for  the  event 
interface  in  the  EC  and  eliminated  ambiguous  cases  such  as  the  start 
event  ocurring  when  the  stop  condition  held. 

3.  At  one  point  we  had  a  special  class  of  processes  called  init 

processes.  We  recognized  these  as  a  special  case  of  Demand  processes 
and  decided  to  simplify  the  interface  by  exploiting  that  fact.  This 
allows  some  processes  to  be  used  both  as  init  processes  and  under 
other  conditions. 

b.  It  is  possible  for  a  programmer  to  write  a  process  that  runs  out  of 
statements  to  execute.  We  considered  three  alternatives: 

a^  Stating  that  it  13  an  undesired  event  for  a  process  to  finish, 
i.e.,  making  it  a  requirement  that  each  process  contain  an 
infinite  loop; 

b)  Assuming  that  a  completed  process  is  in  the  ready  state,  but  that 
it  has  a  null  statement  list  to  execute  if  it  becomes  running; 
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c)  Assuming  that  a  completed  process  is  in  a  waiting  state,  waiting 
for  an  event  that  will  never  occur. 

We  rejected  a)  because  it  builds  too  much  information  into  the 
Extended  Computer  and  it  is  an  unnecessary  restriction.  We  rejected 
b)  because  there  is  no  point  in  having  a  completed  process  compete 
for  a  processor.  Alternative  3  is  a  reasonable  compromise  for  the 
Extended  Computer  interface.  If  it  is  considered  undesirable  to  have 
completed  processes,  this  should  be  prohibited  by  programming 
conventions . 

7.  We  have  decided  not  to  include  relative  priorities  for  the  different 
processes  because  fixed  priorities  do  not  generally  work  when  there 
are  real-time  constraints. 

8.  In  an  earlier  version,  we  had  no  distinction  between  periodic  and 
demand  processes  because  a  periodic  process  can  be  viewed  as  one  that 
waits  for  a  particular  stimulus,  i.e.,  the  passage  of  a  particular 
amount  of  time.  However,  one  of  the  timing  parameters  needed  for 
periodic  processes  is  not  useful  for  demand  processes.  In  addition, 
periodic  processes  must  have  restrictions  on  the  synchronization 
operators  within  the  periodic  loop  because  the  indeterminate  wait 
associated  with  synchronization  operators  makes  it  difficult  to  prove 
that  the  loop  can  be  scheduled  regularly  as  required. 

9.  In  an  earlier  design,  we  did  not  explicitly  distinguish  intermittent 
periodic  processes.  We  now  distinguish  them  in  order  to  increase  the 
likelihood  that  we  can  take  advantage  of  the  intermittency  in  the 
scheduling  of  processes.  Earlier  we  distinguished  them  by  calling 
them  intermittent,  now  we  use  the  presence  of  the  optional  ON__OFF  to 
distinguish  them. 

10.  We  considered  specifying  periodic  processes  in  terms  of  frequency 
rather  than  in  terms  of  time  intervals.  Because  we  wanted  to  specify 
the  deadline  as  an  interval,  we  decid’d  it  would  be  more 
straightforward  to  use  two  intervals.  These  two  parameters 
adequately  constrain  the  variations  in  regularity. 

11.  We  have  an  undesired  event  assumptions  that  says  there  won't  be  too 
many  demand  processes  for  a  periodic  process  to  miss  its  deadline. 

The  assumption  is  worded  with  that  orientation  because  it  is 
impossible  to  tell  how  often  a  demand  process  must  run. 

12.  We  used  to  allow  the  body  of  a  process  to  be  any  statement  list.  We 
now  restrict  it  to  a  call  on  a  previously-declared  program.  In  this 
way  we  maintain  a  clear  distinction  between  process  and  program,  and 
therefore  allow  future  extensions  to  include  run-time  creation  of 
processes  without  run-time  creation  of  programs,  vice  versa.  The 
restriction  does  not  restrict  what  we  can  do  with  the  current 
version;  it  merely  paves  the  way  for  future  extensions. 
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Previously,  there  was  a  parameter  in  the  process  definitions  with 
which  the  user  specified  the  maximum  CPU  time  required  by  his 
process.  We  removed  this  from  the  high-level  EC  interface  because 
(a)  the  user  doesn't  have  enough  information  to  provide  it;  (b^  the 
information  is  machine-dependent;  and  (c)  the  length  of  time  an 
operation  takes  can  vary  greatly,  depending  on  the  storage  and 
representation  of  the  operands,  for  example.  This  is  information  is 
now  provided  to  the  EC  implementation  at  a  lower  level,  where  the 
processes  are  divided  into  scheduling  blocks;  it  may  be  provided  by 
software  that  examines  the  source  code,  or  it  may  be  done  manually. 
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SC. PAR. 2 

1.  Regions  with  an  exclusion  relation  were  selected  for  Extended 
Computer  synchronization  r  imitives  because 

a.  they  allow  concurrency  constraints  to  be  expressed  directly 
rather  than  as  an  implication  of  run  time  synchronization; 

b.  they  express  the  exclusion  relationships  in  a  form  that  can  be 
interpreted  efficiently  by  a  pre-run-time  scheduler; 

c.  there  is  an  algorithm  for  generating  run-time  synchronization 
from  the  exclusion  relations; 

This  is  the  simplest  acceptable  alternative.  Rejected  alternatives 
included : 

a.  disabling  inte-rupt '.on :  once  an  identified  section  of  code 

starts  executing,  it  must  run  to  completion.  This  alternative 
was  rejected  because  it  is  prejudiced  toward  a  single 
processor:  it  overly  restricts  the  parallelism  by  stating  that 

no  other  actions  can  be  taken  simultaneously  with  the  code 
section,  rather  than  specifying  which  other  actions  may  not  be 
taken ; 

b.  simple  mutual  exclusion:  specifies  all  exclusion  relations  as 
equivalent,  i.e.,  a  section  of  code  that  excludes  any  other 
excludes  all  others.  This  alternative  still  places  too  many 
restrictions  on  the  parallelism  because  many  of  the  identified 
code  sections  need  not  exclude  each  other. 

c.  named  regions  with  mutual  exclusion.  Rejected  because  it 
assumes  that  the  exclusion  relation  is  symmetric. 

d.  exclusion  via  synchronization  primitives:  using  synchronization 
primitives  such  as  those  in  EC.SMPH  to  effect  mutual  exclusion. 
Rejected  because  (1)  synchronization  primitives  that  are  being 
used  for  other  interprocess  synchronization  or  communication 
purposes  cannot  be  distinguished  from  those  used  for  exclusion 
without  additional  commentary,  (2)  the  exclusion  requirements 
are  implicit  in  a  solution  based  on  synchronization  primitives, 
rather  than  stated  explicitly  as  they  can  be  with  identifiable 
regions,  and  (3)  the  exclusion  information  (implying  scheduling 
constraints)  is  embedded  in  and  scattered  throughout  the  text. 
These  properties  of  the  synchronism  primitives  make  it  difficult 
to  do  pre-run-time  scheduling  without  substantial  preprocessing. 

2.  Many  useful  forms  of  synchronization  were  rejected  for  the  Extended 
Computer  because  they  do  not  depend  on  the  implementation  of  parallel 
process.  Application-oriented  synchronization  operations  may  be 
developed  using  the  exclusion  relations,  and  semaphores. 

3.  Can  a  region  be  excluded  from  itself?  Is  that  useful?  Yes,  because 
in  the  case  of  non-reentrant  code,  this  is  how  we  will  probably 
prevent  disastrous  re-invocations. 
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EC. PGM. 1 

NOTE:  Design  issues  1  through  7  refer  to  a  previous  control  structure  we  had 

included  in  the  EC  which  is  documented  informally  in  [APC].  That  control 
structure  is  no  longer  a  part  of  EC,  because  we  concluded  that  it  required  too 
much  sophistication  in  implementation,  and  that  simpler  constructs  hid  the 
hardware  characteristics  just  as  well. 

1.  Alternatives  considered  for  the  syntax  of  a  guard  are  shown  below. 

a.  Boolean  variables  or  constants  only.  All  the  boolean  variables 
must  be  assigned  values  before  the  limited  program  is  executed. 

b.  Any  sequence  of  statements  assigning  a  boolean  value  to  a 
special  guarded  command  register. 

c.  Allowing  a  limited  program  list  as  a  guard. 

d.  Allowing  a  program  to  define  the  value  of  a  guard  (defined 
guards ) . 

e.  All  of  the  above. 

Discussion:  We  chose  (e).  The  semantics  can  easily  be  defined 
formally  [ ITTI 2 ] .  Defined  guards  save  code  by  avoiding  duplication 
of  statement  lists,  which  would  otherwise  be  required  because  of 
syntactic  limitations. 

2.  We  chose  to  have  the  Extended  Computer  provide  the  IT-TI  construct 
rather  than  the  more  common  IF-THEN-ELSE ,  CASE,  and  DO-WHILE 
constructs  because  IT-TI  serves  for  all  purposes.  It  allows  some 
programs  to  be  written  as  one  loop  that  would  otherwise  require 
several,  thereby  saving  variables  and  predicate  evaluation.  IT-TI 
has  a  mathematical  semantics  that  allows  systematic  construction  of 
the  program's  function  [iTTIl]. 

3.  Dijkstra's  guarded  commands  are  nondeterministic ;  of  the  true  guards, 
only  one  is  selected,  but  there  are  no  rules  defining  which  one  is 
selected.  We  chose  a  deterministic  construct  because  they  allow 
simpler  guards. 

4.  We  considered  providing  a  FOR  command  (FOR  I  3  1  to  10  DO...)  but 
decided  against  it  because 

a.  the  same  purpose  can  be  served  with  the  IT-TI  command; 

b.  many  special  cases  and  questions  arise  with  the  FOR  command. 

5.  We  considered  having  an  implicit  final  LP  of  the  form  (true, SKIP). 

We  decided  not  to  do  this  in  order  to  encourage  the  programmer  to 
consider  every  case  carefully. 
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6.  Should  statement  lists  be  allowed  to  contain  declarations,  and  what 
is  their  scope?  We  decided  that  it  was  harmless  (from  this  module's 
point  of  view)  to  allow  it.  The  scope  of  all  declarations  is  global 
and  items  must  be  declared  before  they  are  used,  but  these  are  issues 
belonging  to  the  EC  submodules  that  provide  the  declarations. 

7.  In  an  earlier  version  we  allowed  Dijkstra's  cor  and  cand .  We  have 
eliminated  them  because  the  same  effect  can  be  obtained  with  the  use 
of  defined  guards. 
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EC. PGM. 2 

NOTE:  Design  issues  l  through  3  refer  to  a  design  that  allowed  user-defined 

programs  to  have  parameters.  Because  the  semantics  of  parameter  passing  do 
not  depend  upon  the  hardware,  we  concluded  that  users  could  emplov  other 
facilities  to  achieve  a  parameter  protocol  (e.g.,  assignment  before  and  after 
a  program  call') . 

1.  Should  actual  and  formal  parameters  be  specified  by  type  class, 
specific  type  name,  or  using  type  attributes  such  as  range  and 
resolution?  We  decided  that  type  agreement  should  depend  on  the 
specification  chosen  by  the  programmer.  Other  alternatives  would 
force  us  to  write  separate  programs  for  each  specific  type  or  to 
include  a  parameter  passing  mechanism  that  would  be  more  general  than 
needed  for  most  cases. 

2.  We  added  PARM_GIVEN  because  programs  must  be  able  to  tell  if  an 
optional  parameter  was  supplied  or  not.  We  thought  about  making  it  a 
built-in  value  that  any  type  of  variable  could  take  on;  then 
programmers  could  ask,  e.g.,  if  pl=PARM  GIVEN.  However,  because 
output  parameters  can  be  optional,  we  didn't  want  programmers 
checking  their  "value". 

3.  Programmers  need  not  supply  trailing  commas  when  optional  parameters 
at  the  end  of  a  parameter  list  are  omitted.  That  is,  instead  of 
+pgml+(a,b, , , )  one  may  write  +pgml+(a,b).  Besides  the  obvious 
convenience,  this  will  allow  us  to  add  optional  parameters  to  the  end 
of  any  access  program  parameter  list,  yet  not  force  all  calls  on  that 
program  to  change. 

4.  We  added  the  feature  of  ranking  programs'  access  speed  because  the 
current  computer  has  the  capability  of  doing  fast  subroutine  linkages 
in  certain  areas  of  memory.  Because  a  replacement  machine  may  not 
have  such  a  capability,  we  made  the  relationship  "not-slower-than" , 
which  we  can  trivially  implement  by  doing  nothing.  We  make  no  firm 
promise  about  the  ordering,  however,  because  we  recognize  that  we 
cannot  make  access  to  a  subroutine  not-slower-than  access  to  an 
expanded  macro  that  simply  lives  in-line. 

5.  We  considered  giving  the  user  the  ability  to  specify  whether  a 
program  was  to  be  invoked  by  subroutine  linkage  or  in-line  (macro) 
expansion.  Howver,  we  realized  that  macro-expansion  can  be  done 
independently  of  the  host  machine,  and  hence  is  not  an  appropriate  EC 
facility. 
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EC.SMPH 

1.  We  originally  had  more  complex  synchronization  operators  that  met 
many  immediate  demands  of  our  application.  As  we  prefer  the  Extended 
Computer  to  be  as  application-independent  as  Dossible,  we  chose 
synchronization  operations  for  the  Extended  Computer  primitives  that 
would  be  as  simple  as  possible,  but  that  could  be  used  as  building 
blocks  for  more  specialized  synchronization  operators.  For  the  more 
complex  synchronization  operations,  see  the  specifications  of  the 
Application  Data  Type  module  [ADT]. 

All  of  the  following  alternatives  for  the  Extended  Computer 
synchronization  operations  were  rejected  either  because  they  are  more 
complex  than  the  operations  selected  or  because  they  can  be  built, 
given  the  operations  selected. 

a.  P  and  V  operations  on  semaphores; 

b.  eventcounts  [REED79]:  Also  rejected  because  we  weren't  sure  we 
would  need  them; 

c.  ?  and  V  supplemented  by  eventcounts; 

d.  UP,  DOWN,  and  PASS  supplemented  by  event  variables.  A  simple 
generalization  of  event  variables,  event-booleans  can  be 
implemented  in  the  Application  Data  Type  module  in  a  machine 
independent  way. 

e.  V,  DOWN,  PASS,  and  eventcounts. 

2.  At  one  point,  we  provided  a  semaphore-to-integer  conversion  program. 
These  were  deleted  when  we  could  think  of  no  reason  to  use  it.  If 
such  a  need  arises,  it  would  be  a  straightforward  extension,  allowing 
upward-compatab il ity  between  programs  written  now  and  later. 

3.  This  used  to  be  a  submodule  of  EC. PAR,  because  semaphores  are  used  to 
synchronize  processes.  However,  the  secret  of  implementing  them  has 
nothing  to  do  with  processes,  so  semaphores  belong  in  a  module  of 
their  own. 
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1.  The  following  transitions  are  not  included  in  this  interface  for  the 
following  reasons: 

off  to  failed:  not  relevant  to  user  programs; 

failed  to  off:  user  programs  cannot  respond  to  anything 

operating  to  off:  when  the  computer  is  off; 

Note  that  failed  to  operating  does  not  occur  with  the  current 

computer;  it  must  be  cycled  through  "off"  to  get  back  to  operating 

from  failed.  However,  future  computers  may  make  this  transition 
possible  (perhaps  by  re-booting),  and  so  this  transition  is  subsumed 
by  the  definition  of  power  up. 

2.  There  may  not  always  be  a  grace  period  after  flT( ! +fai led  state+I). 

Two  alternatives  were  considered:  to  leave  out  the  grace  period 
altogether,  or  to  include  it  as  a  system-generation  parameter.  We 
selected  the  latter  to  allow  for  future  use  of  an  improved  computer. 

3.  How  do  we  distinguish  between  malfunctions  that  user  programs  must 
detect  and  handle  (possibly  by  calling  +S_FAIL_STATE+)  and 
malfunctions  that  are  detected  inside  the  Extended  Computer? 
Malfunctions  are  detected  by  this  module  if  they  are  reported  bv  the 
computer  without  software  action;  for  example,  malfunctions  signalled 
by  interrupts.  Whenever  a  malfunction  is  detected  because  of  an 
action  dictated  by  the  requirements,  such  as  a  diagnostic  test, 
detection  is  left  to  a  user  program.  The  malfunctions  described  in 
various  test  programs  (EC. PAR. 1,  EC. 10,  EC. MEM,  EC. TIMER)  belong  to 
the  latter  category;  all  others,  the  former. 

i.  Future  technology  may  make  our  three-state  model  appear 

oversimplified,  because  a  system  may  have  degraded  states:  that  is, 
states  without  the  full  capability  of  "operating",  yet  not  dead  in 
the  water  like  "failed".  A  degraded  state  may  occur  in  a 
single-processor  system,  or  in  a  multi-processor  system  where  one  or 
more  processors  have  ceased  to  operate.  It  is  important  that 
acquiring  this  capability  results  in  adding  to  (not  revising)  the 
present  specification.  We  cannot  add  a  degraded  state  now,  because 
we  cannot  implement  and  programs  depending  on  it  would  be  not  be 
correct.  However,  we  can  plan  for  the  addition  by  assuming  that 
there  are  "a£  least  three  states",  etc. 

5.  Which  module  is  responsible  for  the  close-down  procedures?  We 

decided  that  any  shutdown  action  that  is  required  for  every  computer 
failure  and  is  computer-dependent  should  be  done  bv  this  module.  If 
the  action  is  device-dependent,  such  as  setting  the  bomb-release 
output  to  a  safe  value,  it  should  be  done  bv  the  device  interface 
module . 
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1.  In  earlier  versions,  we  had  clocks  and  timers;  clocks  counted  up  and 
timers  counted  down.  They  were  completely  distinct  from  timeint 
entities;  they  were  declared  separately  and  had  their  own  set  of 
operations.  We  removed  the  distinction  as  the  interface  grew  and 
grew,  and  we  realized  that  it  would  be  both  useful  and  consistent  to 
let  a  clock/timer  do  most  anything  that  a  timeint  can  do. 

2.  We  considered  providing  only  clocks  or  only  timers  (in  the  sense  of 
issue  #1).  Clocks  are  useful  for  measuring  elapsed  time;  timers  are 
useful  for  detecting  the  end  of  a  previously  specified  time 
interval.  We  wanted  the  capabilities  of  both  because  otherwise  user 
programs  would  have  to  use  one  to  simulate  the  other.  This  would 
lead  to  inefficiency  and  possible  duplicate  efforts  especially  on  a 
computer  that  provided  both. 

3.  We  considered  having  this  module  offer  a  special  "waittime"  command, 
instead  of  using  the  general  semaphore  mechanism.  There  seems  to  be 
no  advantage  in  using  a  special  mechanism  for  timed  events. 

3.  We  considered  treating  the  following  actions  as  errors: 

-  starting  a  running  timer, 

-  setting  a  running  timer, 

-  stopping  a  non-running  timer, 

-  reading  a  non-running  timer, 

-  stopping  a  timer  that  has  run  down, 

-  reading  a  timer  that  has  run  down, 

but  these  actions  are  not  necessarily  senseless. 

4.  We  considered  having  a  timer  signal  a  UE  if  it  runs  past  its 
capacity.  To  have  it  start  over  seems  the  most  useful.  Further,  a 
timer  might  run  past  its  usual  limit,  for  no  fault  of  the 
software.  In  contrast,  setting  timer  with  too  large  a  value  is  a 
clear  software  error.  Therefore  we  made  exceeding  the  maximum 
capacity  an  undesired  event  in  a  set  operation. 

5.  In  an  earlier  design,  there  was  a  single  maximum  capacity  for  all 
clocks  and  a  single  maximum  for  all  timers.  It  was  pointed  out  that 
clocks  and  timers  are  used  for  very  different  purposes,  some  for 
measuring  very  small  changes  over  a  small  period  of  time,  and  some 
for  keeping  track  of  a  long  period  of  time,  with  less  concern  for 
small  changes.  In  order  to  achieve  this  flexibility  without  undue 
use  of  resources,  we  decided  to  allow  programmers  to  specify  capacity 
and  minimum  measurements  for  individual  timers  and  clocks. 

6.  In  an  earlier  version,  clocks  could  only  be  set  to  zero,  but  this 
seems  unnecessarily  restrictive.  Dwight  Hill:  ”1  believe  we  may 
need  a  +SET_CLOCK+  for  clock  corrections  or  for  time-of-day  clocks." 
The  restriction  went  away  when  we  merged  timers  and  timeints. 
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Timers  used  to  be  a  submodule  of  what  was  called  the  "Sequential 
Execution"  module,  because  programmers  would  presumably  want  to 
transfer  control  based  on  the  value  or  action  of  a  timer.  However, 
the  secret  of  the  timer  module  has  nothing  to  do  with  flow  of 
control,  and  so  it  became  a  module  of  its  own. 
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EC . DATA 

1.  If  the  user  provides  a  subrange  assertion,  the  information  may  be 
used  to  reduce  the  amount  of  operand  shifting  necessary  before  an 
operation  takes  place. 

EC.  10 

1.  The  part  of  the  I/O  submodule  that  handles  the  relation  between  data 
item  names  and  TC-2  instruction  sequences  should  be  a  sysgen  time 
program  and  should  be  table  driven.  It  should  be  organized  into 
submodules  in  accordance  with  the  structure  of  the  Device  Interface 
Module,  because  changes  are  likely  to  be  concentrated  on  individual 
devices . 

EC. MEM:  Contained  in  [VM] 

EC.PAR.l:  None. 

EC. PAR. 2:  None. 

EC.PGM.l:  None. 

EC. PGM. 2 

1.  This  module  does  not  determine  where  programs  are  located  in  memory. 
It  uses  programs  in  the  memory  allocator  module  to  request  space. 

2.  This  module  uses  the  System  Generation  module  to  do  assembly-time 
parameter  type  checking. 


EC. PGM. 3: 

None. 

EC.SMPH: 

None . 

EC . STATE : 

None. 

EC. TIMER: 

None 
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*********************** 

*  BASIC  ASSUMPTIONS  * 
*********************** 


1. 


EC. DATA  .  ! 

i 

The  Extended  Computer  can  provide  one  private  variable  per  process  ' 

(the  register)  that  can  store  values  of  any  type.  Access  to  a 
register  will  usually  be  quicker  than  access  to  other  variables. 


2.  The  attributes  of  a  value  will  be  known  whenever  a  variable  is  used 
as  a  source  or  a  destination.  If  the  attributes  specified  for  the 
variable  when  it  is  used  as  a  source  are  not  the  same  as  were 
specified  when  its  value  was  determined,  the  result  may  be  any  value. 


3.  The  Extended  Computer  can  store  numeric  quantities  with  any  desired 
range  and  resolution.  It  can  be  expected  that  (a)  variables  with  a 
small  range-to-resolution  ratio  will  require  less  actual  memory  space 
than  variables  with  a  large  range-to-resolution  ratio,  and  (b)  that 
operations  on  such  variables  will  be  faster  than  operations  on 
variables  with  a  larger  range-to-resolution  ratio. 


4.  Range  and  resolution  are  adequate  characterizations  of  a  numeric 
variable;  i.e.,  the  needs  of  an  application  progrannner  can  be 
adequately  expressed  by  a  lower  bound,  upper  bound  and  guaranteed 
resolution. 


5.  The  Extended  Computer  can  store  bitstring  quantities  of  any  desired 
length.  Longer  bitstring  entities  may  require  more  storage  than 
shorter  ones.  Operations  on  longer  bitstring  entities  may  require 
more  computer  time  than  operations  on  shorter  ones. 

6.  Whenever  a  numeric  value  is  stored  into  a  variable  with  a  resolution 
different  from  the  source,  the  value  stored  should  always  be  the 
closest  value  that  can  be  represented  in  the  destination.  The 
programmer  need  not  specify  the  conversions  to  be  made;  the  best 
choice  can  be  made  by  the  EC  implementation. 

7.  There  is  no  need  for  operations  that  allow  a  bitstring  value  of  one 
length  to  be  assigned  to  a  bitstring  variable  with  a  different  length. 


8.  The  operations  needed  for  calculating  new  numeric  values  are: 

addition,  multiplication,  division,  subtraction,  absolute  value, 
complement  and  conversions. 
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9.  Division  may  result  in  a  loss  of  all  significance.  This  danger 
cannot  be  hidden  entirely  from  the  programmers,  since  they  may  have 
information  that  can  be  used  to  choose  safe,  efficient  algorithms. 

The  following  division  options  are  sufficient: 

a.  The  quickest  division  can  be  performed  if  the  programmer 
provides  an  upper  bound  for  the  result.  The  better  the  bound, 
the  more  significance  is  preserved.  If  the  bound  is  too  low, 
all  significance  may  be  lost. 

b.  A  slower  algorithm  can  be  used  if  the  programmer  cannot  provide 
an  upper  bound. 

c.  If  the  programmer  cannot  provide  an  estimate  of  the  maximum 
result  and  prefers  to  avoid  the  expense  of  the  slower  algorithm, 
the  Extended  Computer  can  determine  whether  or  not  division  can 
be  safely  performed.  The  EC  can  return  the  sign  of  the  quotient 
even  when  the  operation  cannot  be  safely  performed. 

10.  For  any  variable,  it  is  always  possible  to  implement  a  uniform 
resolution  over  the  entire  range  of  that  variable. 

11.  Whenever  the  program  compares  two  numeric  operands  for  equal i tv, 
programmers  need  to  define  a  threshold,  such  that  if  the  difference 
between  two  numbers  is  less  than  or  equal  to  the  threshold,  the 
numbers  are  considered  equal. 

12.  It  is  acceptable  for  the  results  of  an  operation  to  have  a  larger 
resolution  than  the  resolution  of  the  destination.  The 
approximations  needed  to  store  the  result  can  be  assumed  to  be 
acceptable  for  the  application. 

13.  Only  four  kinds  of  entities  are  needed:  variables,  which  can  be 
changed  at  any  time;  ascons  and  literals,  which  can  be  changed  by 
reassembling  the  program;  and  loadcons,  which  can  be  changed  when  the 
program  is  first  loaded  into  the  computer  but  not  while  it  is  running. 
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14.  The  following  operations  are  sufficient  for  efficiently  producing  new 
bitstring  values  from  existing  bitstring  values: 

a.  AND,  OR,  NAND ,  NOT,  MINUS,  and  XOR,  defined  in  the  usual  way, 
operating  on  corresponding  bits  in  two  operands  of  equal  length; 

b.  SHIFT  operation:  A  bitstring  is  shifted  either  right  or  left  a 
specified  number  of  bits  with  zeros  shifted  into  positions 
vacated  by  the  shift; 

c.  REPLACE  operation:  A  portion  of  a  bitstring  is  replaced  by  the 
value  found  in  an  equal-length  portion  of  another  bitsring; 

d.  CAT  operation:  A  bitstring  is  formed  by  concatenating  two 
previously  existing  bitstrings. 

15.  If  the  result  of  converting  a  real  to  a  bitstring  has  more  bits  than 
the  bitstring  operand,  the  bits  to  the  right  of  the  rightmost  bit  of 
the  destination  bitstring  may  be  ignored. 

16.  Arrays  with  dimensions  that  vary  at  run  time  are  not  needed  in 
avionics  applications. 

17.  Avionics  applications  do  need  arrays  in  which  the  type  class  is  real, 
and  the  elements  are  variables  with  attributes  that  may  vary 
independently  of  the  attributes  of  other  elements  of  the  same  array. 

18.  Arrays  in  which  the  indices  are  not  a  contiguous  subset  of  the 
integers  are  not  needed  in  avionics  applications. 

19.  Avionics  applications  need  to  take  advantage  of  any  capability  that 
the  computer  has  to  allow  faster  memory  access  to  certain  data.  The 
Extended  Computer  can  implement  a  "not-slower-than"  relation  for  any 
two  declared  entities  x  and  y,  so  that  x  will  be  accessed  no  slower 
than  y.  User  programs  can  determine  desired  rankings  at  system 
generation  time;  it  is  not  necessary  to  change  the  rankings  at 
run-time. 
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EC.  10 

1.  The  only  information  needed  by  user  programs  to  identify  inputs  or 
outputs  is  the  data  item  name  given  in  the  requirements  document 
[REQl .  It  is  possible  to  characterize  all  transmissions  between  the 
Extended  Computer  and  its  associated  hardware  as  either  input  or 
output . 

2.  Input  data  items  and  output  data  items  are  bitstring  entities.  Some 
can  only  be  used  as  a  source  in  a  statement  (read-only);  some  can 
only  be  used  as  a  destination  in  a  statement  (write-only);  some  can 
be  used  as  either  (read-write).  No  input  data  item  is  write-only. 

No  output  data  item  is  read-only. 

3.  It  is  possible  to  turn  off  (disable)  input/output  transmissions.  A 
disabled  data  item  has  no  effect  on  and  is  not  affected  by  the 
external  environment. 

4.  No  application  program  will  need  the  identity  code  and  subitem 
identifiers  in  Serial  Input  Register  Data  (see  [REQ]). 

5.  It  is  possible  for  the  software  to  determine  the  success  of  I/O 
operations.  (Of  course,  this  assumption  is  obviously  false  if  we 
consider  hardware  failures.  However  the  correctness  of  our  software 
is  contingent  on  that  assumption.)  An  unsuccessful  operation  may  not 
change  the  value  of  the  associated  data  item. 

6.  Some  input  data  items  are  only  available  intermittently  and  the  EC 
can  notify  user  programs  when  new  values  for  such  data  become 
available. 

7.  Each  i/o  operation  can  be  guaranteed  to  complete  within  a  fixed 
period  of  time.  This  worst-case  timing  requirement  varies  among  data 
items;  the  time  associated  with  each  data  item  can  be  determined  at 
system-generation  time. 

8.  Each  channel  diagnostic  program  may  interfere  with  a  specified  subset 
of  the  input/output  commands.  They  will  not  interfere  with  any  other 
commands . 

9.  Use  of  either  the  discrete  diagnostics  or  the  accelerometer-torque 
diagnostics  may  cause  the  IMS  to  lose  its  alignment  and  velocities 
(i.e.,  have  the  same  effect  as  disabling  the  IMS  temporarily). 
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10.  The  following  aspects  of  the  input/output  can  be  tested  independently 

the  AC  aspects  of  the  signal  converter  channel, 

the  DC  aspects  of  the  signal  converter  channel, 

the  cycle  steal  channel  A  and  serial  input  channel  l, 

the  cycle  steal  channel  B  and  serial  input  channel  2, 

discrete  input  word  1  and  discrete  output  word  1, 

discrete  input  word  2  and  discrete  output  word  2, 

discrete  input  word  3  and  discrete  output  word  3, 

the  IMS  gyro  torque  registers  and  the  accelerometer  accumulators 
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EC. MEM 

1.  A  memory  diagnostic  program  can  check  whether  portions  of  memory  are 
reliable.  This  program  does  not  interfere  with  other  programs.  The 
test  may  take  a  substantial  amount  of  time  to  complete. 

Basic  assumptions  concerning  the  hidden  portion  of  the  interface  may  be 
found  in  [VM] . 
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EC. PAR. 1 

1.  Processes  (executions  of  programs)  may  execute  in  parallel  with  no 
restrictions  on  their  relative  speeds,  except  where  they  are 
explicitly  synchronized  with  each  other  (see  EC. PAR. 2). 

2.  The  number  of  processes  need  not  vary  at  run-time.  It  may  be  set  at 
system  generation  time. 

3.  All  demand  processes  can  start  when  the  system  is  turned  on  (i.e., 
when  (?T(I+power  up+i)  occurs);  some  will  perform  initialization 
routines;  the  remaining  demand  processes  will  wait  for  a  semaphore  to 
become  nonnegative. 

4.  The  process  mechanism  will  be  able  to  detect  the  event 
@T( ! +power  up+! ) . 

5.  Processes  are  not  called  as  subroutines  by  other  programs  and  do  not 
return  control  to  other  programs. 

6.  We  need  only  distinguish  two  process  states:  active  or  suspended .  An 
active  process  can  progress.  A  suspended  process  is  ineligible  to 
progress  (continue  execution). 

7.  The  state  of  a  process  changes  between  active  and  suspended  only  when 
it  uses  the  process  synchronization  mechanisms  described  in  sections 
EC. PAR. 2  and  EC.SMPH  or  when  it  has  executed  the  last  statement  in 
its  body. 

8.  All  processes  are  either  periodic  or  demand  and  exist  throughout  the 
life  of  the  system; 

The  bodies  of  periodic  processes  are  to  be  executed  at  regular 
intervals  (their  period).  The  period  of  a  process  may  change  during 
system  execution.  A  periodic  process  may  be  suspended  when  a 
specified  boolean  variable  is  false  and  start  again  when  it  is  true. 

Demand  processes  wait  for  a  semaphore  to  be  nonnegative.  They  should 
be  executed  each  time  the  semaphore  is  incremented.  They  will 
decrement  the  semaphore  once  per  execution. 

9.  Demand  processes  can  be  adequately  characterized  by  specifving  the 
values  of  two  timing  parameters:  maximum  CPU  time  requirement  and 
deadline  for  completion. 


10.  Periodic  processes  are  adequately  characterized  by  three  timing 
parameters:  maximum  CPU  time  requirement,  deadline,  and  period. 
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EC. PAR. 2 

1.  User  programs  may  contain  contiguous  sections  or  regions  of 
run-time-executable  statements  that  may  not  be  executed 
concurrently.  These  concurrency  constraints  can  be  expressed  in 
terms  of  an  exclusion  relation  on  the  regions,  i.e.,  where  region  1 
excludes  region  2  if  region  2  may  not  start  while  region  1  is 
executing. 

2.  Regions  may  overlap  other  regions  or  be  embedded  in  other  regions. 
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EC. PGM. 1 

1.  The  only  sequence  control  constructs  needed  are  those  that  choose  a 
path  based  upon  the  results  of  the  invocation  of  a  program. 

2.  The  number  of  entrances  and  exits  of  a  program  is  finite,  and  the 
upper  bound  can  be  determined  at  system  generation  time. 
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EC. PGM. 2 

1.  Some  program  entities  should  be  invoked  faster  than  others.  Such  a 
relation  will  not  depend  on  when  the  programs  are  invoked;  the 
relative  ranking  can  be  determined  at  system  generation  time. 

2.  It  is  not  necessary  to  provide  users  with  the  capability  to  create 
programs  that  take  parameters.  Other  mechanisms  available  to  him 
(such  as  assignment  before  and  after  the  "body"  of  the  program) 
suffice. 

3.  It  is  necessary  to  provide  facilities  for  recovery  if  a  programming 
error  is  detected  by  a  program  during  execution.  It  is  up  to  the 
author  of  a  called  program  to  determine  what  programming  errors  his 
program  can  detect;  it  is  up  to  the  caller  of  a  program  to  determine 
the  action  that  should  be  taken  if  one  of  those  errors  occurs.  It  is 
not  necessary  to  pass  parameters  to  the  recovery  program. 
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EC. PGM. 3 

1.  if  a  program  will  be  reentered  while  already  in  use  by  another 
process,  it  is  the  responsibility  of  the  programmer  to  make  sure  that 
local  storage  is  saved  and  restored  as  needed.  EC  programs  are  lot 
automatically  provided  with  new  storage  when  they  are  reentered. 

2.  There  is  no  need  for  a  mechanism  to  allow  programs  to  cause  the 
calling  program  to  resume  execution  anywhere  else  than  immediately 
after  the  call. 

3.  The  identity  of  a  data  entity  that  is  passed  to  an  EC  access  program 
as  an  actual  parameter  will  not  be  changed  while  the  program  is 
executing.  For  example,  when  an  array  element  is  passed  as  an  actual 
parameter  to  a  program,  if  that  program  alters  the  value  of  the 
variables  that  determined  the  index,  the  results  will  be  undefined. 

4.  Parameters  always  fall  into  one  of  three  classes:  input,  output,  or 
input-output . 
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EC.SMPH 

1.  There  are  two  process  states  relative  to  synchronization:  active 
(which  includes  processes  that  are  running  and  processes  that  are 
ready)  and  suspended  (ineligible  to  make  progress).  The  active 
processes  are  the  only  ones  eligible  for  execution. 

2.  The  only  operations  on  semaphores  that  need  to  be  executed  in  a  way 
that  guarantees  non-interference  with  other  operations  on  semaphores 
are  the  following: 

a.  An  operation  that  does  not  affect  the  counter  value  of  the 
semaphore,  but  may  put  the  process  in  the  waiting  state. 

b.  An  operation  to  decrement  the  semaphore  counter  without  any 
effect  on  the  state  of  the  process  that  executes  it. 

c.  An  operation  to  increment  the  semaphore  counter  that  may  put 
other  processes  in  the  active  state. 
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EC. STATE 

1.  The  Extended  Computer  has  at  least  three  states:  off,  operating,  and 
failed.  Only  the  following  transitions  between  states  affect  user 
programs : 

-  from  off  to  operating 

-  from  operating  to  failed. 

2.  User  programs  cannot  cause  the  transition  into  the  operating  state. 

3.  A  transition  from  operating  to  failed  can  either  be  caused  by  user 
programs  or  occur  when  malfunctions  internal  to  the  Extended  Computer 
are  detected.  These  internal  malfunctions  are  other  than  those 
described  in  test  programs  contained  in  EC. PAR. 1,  EC. TIMER,  EC. MEM, 
and  EC. 10.  It  should  be  assumed  that  after  this  transition  occurs, 
user  programs  will  have  at  least  a  short  interval  to  execute 
shut-down  sequences  before  the  computer  stops  operating.  The  minimum 
length  of  the  interval  before  shut-down  can  be  determined  at 
system-generation  time. 

4.  Any  actions  that  must  be  taken  when  a  computer  failure  occurs  are 
independent  of  the  state  of  the  user  programs,  and  can  be  built  into 
the  EC. 
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EC. TIMER 

1.  Avionics  programs  need  timers  that  Veep  track  of  elapsed  time,  and 
that  may  signal  when  a  given  time  interval  has  elapsed.  They  need  to 
be  able  to  set  a  timer  to  a  starting  value,  start  it,  stop  it,  and 
read  it  whether  it  is  running  or  not. 

2.  The  maximum  timing  capacity  of  a  clock  or  a  timer  can  be  determined 
at  system  generation  time. 

3.  If  a  timer  runs  beyond  a  limit  specified  at  run  time,  it  should 
either  halt  or  start  over.  Sometimes  it  should  signal  that  a  range 
limit  has  been  reached. 

5  The  worst  acceptable  error  rate  for  all  timers  can  be  determined  by 
users  at  system  generation  time.  This  error  can  be  specified  as  a 
fraction  of  the  running  time. 

6.  Any  number  of  timers  can  be  implemented,  provided  that  the  number  is 
known  at  system-generation  time.  There  is  no  need  to  create  or 
delete  timers  at  run  time. 

7.  There  are  diagnostic  programs  that  can  test  the  hardware  timers  and 
the  interrupt  mechanism  separately,  but  may  interfere  with  proper 
execution  of  other  programs. 
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**************************************** 

*  ASSUMPTIONS  ABOUT  UNDESIRED  EVENTS  * 
**************************************** 


EC. DATA 

1.  User  programs  will  not  divide  by  zero. 

2.  The  result  of  any  operation  will  not  be  outside  the  range  of  the 
destination  variable. 

3.  In  a  replace  operation,  user  programs  will  not  specify  positions  that 
do  not  appear  within  bitstrings  or  specify  a  substring  with  a  start 
position  that  is  higher  than  the  stop  position. 

4.  After  converting  a  numeric  value  to  a  bitstring,  there  will  be  no 
bits  to  the  left  of  the  most  significant  bit  of  the  destination 
bitstring. 

5.  Users  will  not  supply  a  parameter  in  an  array  reference  that  is  not 
in  the  index  set  of  the  array. 


EC.  10 

1.  User  programs  will  not  attempt  to 

-  use  an  enabled  read-write  input  data  item  as  a  ! '.destination!  1 ; 
or 

-  use  an  enabled  read-write  output  data  item  as  a  !! source!!. 

2.  User  programs  will  not  disable  (enable)  a  data  item  that  is  already 
disabled  (enabled). 


EC. MEM 

None.  For  UE  assumptions  about  the  hidden  portion  of  the  interface,  see  [VM]. 


EC. PAR. 1 

1.  Demand  processes  will  not  need  to  run  so  often  as  to  cause  a  periodic 
process  to  miss  its  deadline. 

2.  A  periodic  process  will  have  a  period  greater  than  its  deadline. 
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None . 


EC. PAR. 2 


EC. PGM. 1 

1.  Every  program  exit  that  will  be  chosen  during  execution  will  be 
connected  to  a  succeeding  command. 


EC. PGM. 2 

1.  A  user  will  not  fail  to  assign  a  value  to  a  built-in  EC  program 
variable. 


EC. PGM. 3 


1.  A  program  will  not  invoke  itself. 


EC.SMPH 

1.  There  is  a  range  of  values  that  will  suffice  for  all  semaphores, 
will  not  be  exceeded  by  user  programs. 


EC. STATE. 3 

None. 

EC. TIMER 

None. 
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UNIMPLEMENTED  EXTENDED  COMPUTER  FACILTIES 


Not  all  of  the  capabilities  described  in  this  document  have  been  provided 
in  the  current  version  of  the  Extended  Computer.  A  few  facilities,  which  are 
not  currently  needed  by  the  application  program,  have  not  been  implmented.  An 
attempt  to  use  an  absent  facility  will  result  in  an  undesired  event  in  the 
development  version.  The  unimplemented  features  are  described  below. 


FEATURE : 

WHERE  DESCRIBED: 
UNDESIRED  EVENT: 
CURRENT  USE: 


Periodic  processes  with  periods  that  vary  at  run-time 
EC. PAR. 1 

?%un implemented  variable  period?? 

The  I+period+!  parameter  in  the  ++P_PROCESS++  must  be 
given  as  an  ascon  or  a  literal. 


FEATURE : 

WHERE  DESCRI3ED: 
UNDESIRED  EVENT: 
CURRENT  USE: 


Ability  to  enable/disable  all  data  items 
EC. TO 

??unirap lamented  disabling?? 

Only  the  following  data  items  may  be  disabled; 
attempting  to  +DISABLE+  or  +ENABLE+  any  other  is 


prohibited. 

/ /ASAZ/ / 

//ASLEL// 

//AZRING// 

//CURAZSIN// 

//FLTDIRAZ// 

//HUDAS// 

/ /HUDPUC/ / 
//HUDWARN// 
//MAGHDGH/ / 

/ /PUACAZ// 

//ROLLSINH// 

//VERTVEL// 

/ /XCOMMF// 


//ASEL// 

/ /ASLCOS// 
//BAROHUD// 
// CURPOS// 

/ /FPMAZ/ / 

/ /HUDASL// 
//HUDSCUE// 
//LSOLCUAZ/ / 
//MAPOR// 

/ /PUACEL// 

/ /USOLCUAZ/ / 
/ /VTVELAC// 
//YCOMM/ / 


//ASLAZ/ / 

/ / ASLSIN/ / 

//CURAZCOS// 

//DESTPNT// 

/ /FPMEL// 
//HUDFPM/ / 
//HUDVEL// 
//LSOLCUEL/ / 
/ /PTCHANG/ / 
//ROLLCOSH// 
//USOLCUEL// 
/ /XCOMMC / / 


FEATURE : 

WHERE  DESCRIBED: 
UNDESIRED  EVENT: 
CURRENT  USE: 


Bitstrings/timeints/Dointers  with  attributes  that  can 
vary  at  run-time 
EC. DATA 

??unimplemented  binding?? 

In  the  ++DCL  TYPE++  program,  users  may  not  declare  the 
binding  of  bitstring  or  timeint  or  pointer  specific 
types  to  be  VARY. 
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FEATURE : 

WHERE  DESCRIBED: 
UNDESIRED  EVENT: 
CURRENT  USE: 


Timers  with  attributes  that  can  vary  at  run-time 
EC. TIMER 

ZZunimpleraented  binding%% 

In  the  ++DCL_TYPE++  program  for  timers,  users  mav  not 
declare  the  binding  of  timers  to  be  VARY. 


FEATURE : 

WHERE  DESCRIBED: 
UNDESIRED  EVENT: 
CURRENT  USE: 


Semaphores  with  attributes  that  can  vary  at  run-time 
EC.SMPH 

%%unimplemented  binding%% 

In  the  ++DCL_TYPE++  program  for  semaphores,  users  may 
not  declare  the  binding  of  semaphores  to  be  VARY. 


FEATURE : 

WHERE  DESCRIBED: 
UNDESIRED  EVENT: 
CURRENT  USE: 


Programs  with  attributes  that  can  vary  at  run-time 
EC. PGM. 2 

ZZunimplemented  binding%% 

In  the  ++DCL_TYPE++  program  for  programs,  users  may 
not  declare  the  binding  of  programs  to  be  VARY. 


FEATURE : 

WHERE  DESCRIBED: 
UNDESIRED  EVENT: 
CURRENT  USE: 


Undesired  events  in  the  production  EC 

Throughout 

none 

In  the  production  version  of  the  Extended  Computer,  no 
undesired  events  will  be  checked  for;  no  undesired 
event  handling  programs  will  be  assembled  or 
executed.  It  will  be  assumed  that  user  programs  will 
invoke  the  EC  facilities  correctly. 


FEATURE : 

WHERE  DESCRIBED: 
UNDESIRED  EVENT: 
CURRENT  USE: 


Specifying  substrings  of  bitstrings  with  variables 
EC. DATA. 2. 7. 2 

ZZunimplemented  variable  substring%% 

In  the  bitstring  +REPLC+  program,  p2,  p3,  and  p4  must 
be  given  by  literals  or  ascons. 


FEATURE : 

WHERE  DESCRIBED: 
UNDESIRED  EVENT: 
CURRENT  USE: 


Specifying  the  length  of  a  bitstring  shift  with  a 

variable 

EC. DATA. 2. 7. 2 

ZZ unimplemented  variable  shift  lengthZZ 

In  the  +SHIFT+  program,  p2  must  be  given  by  a  literal 

or  an  ascon. 
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FEATURE : 

WHERE  DESCRIBED: 
UNDESIRED  EVENT: 
CURRENT  USE: 


FEATURE : 

WHERE  DESCRIBED: 
UNDESIRED  EVENT: 
CURRENT  USE: 


FEATURE : 

WHERE  DESCRIBED: 
UNDESIRED  EVENT: 
CURRENT  USE: 


FEATURE : 

WHERE  DESCRIBED: 
UNDESIRED  EVENT: 
CURRENT  USE: 


FEATURE : 

WHERE  DESCRIBED: 
UNDESIRED  EVENT: 
CURRENT  USE: 


FEATURE: 

WHERE  DESCRIBED: 
UNDESIRED  EVENT: 
CURRENT  USE: 
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Unimplemented  Features 


Using  variables  to  specify  attributes  of  a  specific 
type,  or  of  a  variable  or  array  with  varying  attributes 
EC. DATA. 3,  EC.SMPH. 3,  EC. TIMER. 3 
%%un imp  lamented  attribute  via  variables%% 

To  specify  an  attribute  (as  defined  in  EC. DATA. 3),  a 
timer-attribute  (as  defined  in  EC. TIMER. 3),  or  a 
semaphore-attribute  (as  defined  in  EC.SMPH. 3), 
literals  or  ascons  must  be  used. 


Allowing  the  EXACT_REP  attribute  to  vary  for  numeric 
types. 

EC. DATA. 2. 4,  EC. DATA. 3 
%%unimplemented  varying  EXACTJREP%% 

If  a  type  is  declared  to  have  varying  attributes,  and 
is  given  an  initial  attribute  that  includes  EXACTj_REP 
then  it  may  not  later  be  assigned  attributes  that  do 
not  include  EXACT  REP;  the  converse  is  also  true. 


Using  Che  EXACT_REP  attribute  for  any  resolution. 
EC. DATA. 3 

%%un implemented  EXACT_REP  resolution%% 

Whenever  a  type  has  the  EXACT_REP  attribute,  its 
resolution  must  be  an  exact  power  of  two. 


Checking  parameter  type  when  it  is  given  by  a  pointer. 

EC. DATA 

None. 

If  an  ! '. actual  parameter!',  is  given  by  naming  a 
pointer  to  an  entity,  and  that  entity  is  not  of  the 
proper  type  as  required  by  the  program  being  invoked, 
the  result  will  be  unpredictable;  no  UE  will  be  raised. 


Checking  if  a  !  '.destination! '.  is  not  a  variable  when 
it  is  given  by  a  pointer. 

EC. DATA 
None . 

If  an  ! Idestination! !  is  given  by  naming  a  pointer  to 
an  entity,  and  that  entity  is  not  a  variable,  the 
result  will  be  unpredictable;  no  UE  will  be  raised. 


Pointers  pointing  to  programs  that  have  parameters. 

EC. DATA,  EC. PGM. 2 

%%un implemented  pgm  ptr%Z 

A  pointer  may  only  refer  to  user-defined  programs  or 
to  parameter  less  EC  access  programs. 
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FEATURE : 

WHERE  DESCRIBED: 
UNDESIRED  EVENT: 
CURRENT  USE: 


FEATURE : 


WHERE  DESCRIBED: 
UNDESIRED  EVENT: 
CURRENT  USE: 
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Un implemented  Features 


Defining  a  program  with  more  than  one  entrance. 

EC. PGM. 1 

%%unimpleraented  multi-entrance  pgm«%. 

A  user  may  not  supply  more  than  one  entrance  name  in 
any  invocation  of  ++ENTRANCE++.  The  UE  %%entrance 
incorrectly  omitted%%  of  EC. PGM. 3  will  not  be  checked 
for,  in  lieu  of  the  above  UE. 


EC  access  programs  that  compute  a  single  output 
parameter  having  more  than  one  exit,  unless  the 
parameter  is  real  or  boolean. 

EC. PGM. 1 

%%unimplemented  multi-exit  EC  access  program%2 
Only  EC  access  programs  computing  a  single  output 
parameter  that  is  real  or  boolean  have  more  than  one 
exit  as  described  in  EC. PGM. 1 . 2 . 1 .  Invocations  of 
other  EC  access  programs  that  compute  a  single  result 
must  be  followed  by  an  exit-list  of  the  form  : label 
or  by  a  null  exit-list. 
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APPENDIX  5 

INPUT/OUTPUT  DATA  ITEM  NAMES 


The  following  table  lists  all  data  items  available  from  the  Extended 
Computer,  gives  the  bitstring  spectype  of  each,  and  tells  whether  each  one  is 
read-only  (R),  write-only  (W) ,  or  read-write  (RW).  The  length  of  each  item  is 
embedded  in  its  spectype  name. 

INPUT  DATA  ITEMS  OUTPUT  DATA  ITEMS 


Data  item 

Data  item 

name 

R  or  RW 

Spectype 

name  W 

or  RW 

Spectype 

/ACAIRB/ 

R 

BIOl 

//ANTSLAVE// 

W 

BIOl 

/ADCFAIL/ 

R 

BIOl 

/ / ASAZ/ / 

RW 

3HUD12 

/  AOA/ 

R 

BAOA12 

//ASEL// 

RW 

BHUD12 

/ANTGOOD/ 

R 

BIOl 

//ASLAZ// 

RW 

BHUD12 

/ARPINT/ 

R 

BARP8 

/ / ASLCOS/ / 

RW 

BHUD12 

/ ARPPAIRS/ 

R 

BIOl 

// ASLEL// 

RW 

BHUD12 

/ARPQUANT/ 

R 

BARP8 

//ASLSIN // 

RW 

BHUD12 

/BAROADC/ 

R 

BADC12 

//AUTOCAL// 

W 

BIOl 

/BMBDRAG/ 

R 

BIOl 

/ / AZRING/ / 

RW 

BMAP12 

/BRGSTA/ 

R 

BTACll 

//BAROHUD// 

RW 

BHUD1B 

/DIMWC/ 

R 

BIOl 

//BMBREL/ / 

W 

BIOl 

/DGNDSP/ 

R 

BDRS14 

//BMBTON/ / 

W 

BIOl 

/DRFTANG/ 

R 

BDRS14 

/ /BRGDEST// 

W 

BHSI13 

/DRSFUN/ 

R 

BDRS3 

/ / COMPCTR/ / 

W 

BIOl 

/DRSMEM/ 

R 

BIOl 

/ / COMPFAIL/ / 

W 

BIOl 

/DRSREL/ 

R 

BIOl 

//CURAZCOS// 

RW 

BFLRCUR13 

/ELECGOOD/ 

R 

BIOl 

//CURAZSIN// 

RW 

BFLRCUR13 

/FLYTOTOG/ 

R 

BPNL2 

/ /CURENABL/ / 

w 

BIOl 

/FLYTOTW/ 

R 

BPNL4 

//CURPOS// 

RW 

BFLRCUR12 

/GUNSSEL/ 

R 

BIOl 

/ /DESTPNT// 

RW 

BMAP12 

/HUDREL/ 

R 

BIOl 

//ENTLIT// 

W 

BIOl 

/ IMSAUTOC/ 

R 

BIOl 

//FIRRDY// 

w 

BIOl 

/IMSMODE/ 

R 

BIMS5 

//FLTDIRAZ/ / 

RW 

BHUD12 

/ IMSREDY/ 

R 

BIOl 

//FLTREC// 

w 

See  note  3 

/ IMSREL / 

R 

BIOl 

//FPANGL// 

w 

BFLRFPA11 

//FPMAZ/ / 

RW 

BHUD12 

//FPMEL// 

RW 

BHUD12 

//GNDTRK// 

W 

BHST13 
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Data  Item  Names 


INPUT  DATA  ITEMS  OUTPUT  DATA  ITEMS 


Data  item 

name 

R  or  RW 

Spectype 

Data  item 

name  W 

or  RW 

Spectype 

/KBDINT/ 

R 

BPNL10 

//GNDTRVEL// 

W 

BFLR10 

./LOCKE  DON/ 

R 

3101 

//HUDAS // 

RW 

3101 

/MA/ 

R 

BI01 

//HUDASL// 

RW 

BIOl 

/MACH/ 

R 

BIMS12 

//HUDFPM// 

RW 

BIOl 

/MAGHCOS/ 

R 

BIMS13 

//HUDPUC// 

RW 

BIOl 

/MAGHSIN/ 

R 

BIMS13 

//HUDSCUE// 

RW 

BIOl 

/MFSW/ 

R 

BMFS5 

//HUDVEL// 

RW 

BIOl 

/MODEROT/ 

R 

BPNL6 

//HUDWARN// 

RW 

BIOl 

/MULTRACK/ 

R 

BI01 

//IMSNA// 

W 

BIOl 

/PCHCOS/ 

R 

BIMS13 

//IMSSCAL// 

w 

BIOl 

/PCHSIN/ 

R 

BIMS13 

//KELIT// 

w 

BIOl 

/PMDCTR/ 

R 

3101 

//LATGT70// 

w 

BIOl 

/PMHOLD/ 

R 

BI01 

//LFTDIG// 

w 

BIOl 

/PMNORUP/ 

R 

BI01 

//LLITDEC/ / 

w 

BIOl 

/PMSCAL/ 

R 

BI01 

//LLITE// 

w 

BIOl 

/PMSLAND/ 

R 

BI01 

//LLIT322// 

w 

BIOl 

/PNLTEST/ 

R 

BI01 

//LLITW/ / 

w 

BIOl 

/PRESPOS/ 

R 

BPNL3 

//LSOLCUAZ // 

RW 

BHUD12 

/RAD ALT/ 

R 

BRA12 

//LSOLCUEL// 

RW 

BHUD12 

/RE/ 

R 

BI01 

/ /LWDIG1// 

w 

BPNL7 

/RNGSTA/ 

R 

BTAC14 

//LWDIG2// 

w 

BPNL7 

/ROLLCOSI/ 

R 

BIMS13 

/ /LWDIG3// 

w 

BPNL7 

/ROLLSINI/ 

R 

BIMS13 

//LWDIG4// 

w 

BPNL7 

/SINEVEL/ 

R 

See  note  1 

//LWDIG5// 

w 

BPNL7 

/SINHDG/ 

R 

See  note  1 

//LWDIG6 // 

w 

BPNL7 

/SINLAT/ 

R 

See  note  1 

/ /LWDIG7// 

w 

BPNL7 

/SINLONG/ 

R 

See  note  1 

//MAGHDGH// 

RW 

BHUD11 

/SINNVEL/ 

R 

See  note  1 

//MAPOR// 

RW 

BMAP12 

/ SINPTH/ 

R 

See  note  1 

//MARKWIN// 

W 

BPNL7 

/SINROL/ 

R 

See  note  1 

//PTCHANG// 

RW 

BHUD12 

/SLEWRL/ 

R 

BSLEW13 

/ /PUACAZ// 

RW 

BHUD12 

/ SLEWUD/ 

R 

BSLEW13 

//PUACEL// 

RW 

BHUD12 

/ SLTRNG/ 

R 

BFLRSR13 

//RNGHND/ / 

W 

BMAP8 

/STA1RDY/ 

R 

BI01 

//RNGTEN// 

w 

BMAPB 

/STA2RDY 

R 

BI01 

/ /RNGUNIT/ / 

w 

BMAP8 

/ STA3RDY/ 

R 

BI01 

//ROLLCOSH// 

RW 

BHUD12 

/ STA6RDY/ 

R 

BIO! 

//ROLLSINH// 

RW 

BHUD12 

/ STA7RDY/ 

R 

BIOl 

//STEERAZ// 

W 

BFLRSTR13 

/ STA8RDY/ 

R 

BI01 

//STEEREL// 

W 

BFLRSTR13 

/TD/ 

R 

BIOl 

//STERROR// 

W 

BAD! 11 

/TAS/ 

R 

BADC12 

/ /TSTADCFLR/ / 

W 

BIOl 

/THDGCOS/ 

R 

BIMS13 

//ULITN// 

W 

BIOl 

/THDGSIN/ 

R 

BIMS13 

/ /ULITS// 

W 

BIOl 

/UPDATTW/ 

R 

BPNL4 

/ /ULIT222 

W 

BIOl 
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Release  7 


INPUT  DATA  ITEMS 


OUTPUT  DATA  ITEMS 


Data  item 

name 

R  or  RW 

Spectype 

/WAYLAT/ 

R 

See  note  2 

/WAYLON/ 

R 

See  note  2 

/WAYNUM1/ 

R 

See  note  2 

/WAYNUM2/ 

R 

See  note  2 

/WEAPTYP/ 

R 

BASCU8 

/XGYCNT/ 

R 

BIMS2 

/XVEL/ 

R 

B  IMS  10 

/YGYCNT/ 

R 

BIMS2 

/YVEL/ 

R 

BIMS10 

/ZGYCNT/ 

R 

BIMS2 

/ZVEL/ 

R 

BIMS10 

Data  item 


name 

W  or  RW 

Spectype 

/ /ULIT321// 

W 

BIOl 

/ /USOLCUAZ/ / 

RW 

BHUD12 

//USOLCUEL// 

RW 

BHUD12 

//UWDIG1// 

W 

BPNL7 

/ /UWDIG2/ / 

W 

BPNL7 

// UWDIG3// 

W 

BPNL7 

//UWDIG4// 

W 

BPNL7 

//UWDIG5// 

W 

BPNL7 

/ /UWDIG6// 

w 

BPNL7 

//VERTVEL// 

RW 

BHUD12 

/ /VTVELAC/ / 

RW 

BHUD12 

/ /XCOMMC/ / 

RW 

BMAP9 

//XCOMMF// 

RW 

BMAP13 

//XGYCOM// 

W 

BIMS4 

//XSLEW// 

W 

BIOl 

//XSLSEN// 

W 

BIOl 

/ /YCOMM/ / 

RW 

BMAPll 

/ /YGYCOM/ / 

W 

BIMS4 

//YSLEW// 

W 

BIOl 

//YSLSEN// 

W 

BIOl 

/ /ZGYCOM/ / 

W 

BIMS4 

//ZSLEW// 

W 

BIOl 

//ZSLSEN// 

W 

BIOl 

Notes 


1.  The  spectype  of  this  item  is  BSINSn,  where  "n"  is  the  length  of  the 
item.  The  length  may  be  determined  by  consulting  the  confidential 
addendum  to  [REQ]. 

2.  The  spectype  of  this  item  is  BWISn,  where  "n"  is  the  length  of  the 
item.  The  length  may  be  determined  by  consulting  the  confidential 
addendum  to  [REQ]. 

3.  //FLTREC//  is  an  array  of  type  BFLTREC16.  The  number  of  elements  is 
given  by  the  integer  system  generation  parameter  *nbr  fltrec  elements*. 
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The  following  data  items  have 
semaphore)  associated  with  them: 

Event 


1TC+/EHTERSW/  occurred*:) 
@T( :+/KBDENBL/  occurred*!) 
@T( 1+/MARKSW/  occurred* I) 
@TC:+/KBDINT/  ready*!) 


events  (signalled  by 


Semaphore 

ENTSWSEM 

ENBLSEM 

MARKSEM 

KBINTSEM 


APPENDIX  6 


DATA  REPRESENTATION  CATALOGUE 


For  some  specific  types,  the  Extended  Computer  is  capable  of  providing 
more  than  one  kind  of  representation.  The  version  has  no  effect  on  the 
outcome  of  an  EC  operation,  but  some  versions  allow  some  operations  to  be 
performed  more  efficiently  than  other  versions. 

The  following  table  lists  the  provided  version  names  for  each  EC  specific 
type  which  has  more  chan  one  version.  When  declaring  a  specific  type,  users 
may  request  a  particular  version  by  using  these  names. 


Typeclass 


Specific  type  Version  names  Version 


properties 


REAL 

Any 

BITSTRING 

Any 

TIMEINT 

Any 

TIMER 

Any 

SEMAPHORE 

Any 

PGM 

Any 

R1 

B1 

Tl 

Cl 

SI 

PI 


aasssaaasaassssaaaaaasaaiMa 


N/A 

N/A 

N/A 

N/A 

N/A 

N/A 
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f  ADT] 

( APC  ] 

[ BELP73 ! 
[DIJK68] 

[ DIJK77 1 
[DIM] 

[REED79] 

[REQ] 

[SO] 

[TRACE] 

[VM] 

[WUER76] 
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